home *** CD-ROM | disk | FTP | other *** search
/ Complete Linux / Complete Linux.iso / docs / apps / database / postgres / postgre2.z / postgre2 / doc / release4.0.1.m < prev   
Encoding:
Text File  |  1992-08-27  |  8.1 KB  |  217 lines
  1. .\"
  2. .\"    release4.0.1.me:  postgres version 4.0.1 release notes.  print using
  3. .\"            psroff -me.
  4. .\"
  5. .nr pi 3n
  6. .nr si 2n
  7. .nr pp 11
  8. .nr tp 11
  9. .nr sp 11
  10. .de RV
  11. .ie "\\$2"" \
  12. \{\
  13. .    ds VN "0.0
  14. .    ds VD "(No date)
  15. .    ds VT "UNAUDITED VERSION
  16. .\}
  17. .el \
  18. \{\
  19. .    ds VN \\$3
  20. .    ds VD \\$4
  21. .    ie "\\$7"Exp" \
  22. .        ds VT "DRAFT
  23. .    el \
  24. .        ds VT \\$7
  25. .\}
  26. ..
  27. .de CW
  28. \\fC\\$1\\fP\\$2
  29. ..
  30. .RV $Header: /private/postgres/doc/RCS/release4.0.1.me,v 1.4 1992/08/26 22:57:12 mer Exp $
  31. .ds PG "\\s-2POSTGRES\\s0
  32. .ds PQ "\\s-2POSTQUEL\\s0
  33. .ce 99
  34. .ft B
  35. .ps 14
  36. \*(PG Version 4.0.1
  37. .sp 0.5v
  38. Release Notes
  39. .sp
  40. .ps 11
  41. \*(VD
  42. .ce 0
  43. .he '\*(PG V4.0.1 Release Notes'%'\*(VD'
  44. .sp 2
  45. .sh 1 "Introduction"
  46. .pp
  47. These are the release notes for version 4.0.1
  48. of the \*(PG database system from UC Berkeley.
  49. The database system and its installation procedure
  50. are covered in detail in the setup document for this release,
  51. which can be found in the file ~postgres/doc/postgres-setup.me.
  52. Here, we cover only the most important differences from release
  53. 4.0 and earlier versions of the system.
  54. .sh 1 "Aim"
  55. .pp
  56. The main focus of this release was an attempt to fix the reported
  57. bugs in version 4.0.  Because of this, no new 
  58. functionality has been added to the system.  The sole
  59. development effort was in fixing bugs reported by users of version 4, and
  60. bugs uncovered by a first cut at system validation test suites.
  61. .sh 1 "Existing 4.0 Databases"
  62. .pp
  63. There have been no changes to the tuple header structures or the system
  64. catalogs since \*(PG Version 4.0.  Because of this you do not have to do
  65. the \*(PG data conversion dance after installing 4.0.1.  The entire data
  66. directory can be copied from the 4.0 installation to the 4.0.1 installation.
  67. Here is a suggested means of conversion (if you have the disk space).
  68. .(l
  69. .ft C
  70. Once 4.0.1 is installed in /usr/postgres:
  71.  
  72.     rm -rf /usr/postgres/data
  73.     cd /usr/postgres4.0
  74.     tar cf - data | (cd /usr/postgres; tar xvf -)
  75. .ft P
  76. .)l
  77. If there are any problems, remove /usr/postgres/data, run initdb and fall
  78. back to the tried method of copying.
  79. .b "Note that this will only work with Version 4 databases."
  80. Databases from 3.1 (or earlier releases) must still be copied out to unix
  81. files, then copied back in once 4.0.1 has been successfully installed.
  82. .sh 1 "New Debugging Tools"
  83. .pp
  84. Both of the following utilities are built and installed in $POSTGRESHOME/bin
  85. during the standard installation procedure.  If you think you are experiencing
  86. database corruption, we encourage you to try them out.
  87. .sh 2 "pagedoc"
  88. .pp
  89. Pagedoc is a postgres relation page doctor.  It requires the path name of a
  90. heap or an index relation as an argument.  It understands postgres page
  91. formats and can be used to dump the pages.  Pagedoc doesn't know about user
  92. data in tuples; it only knows about tuple headers which are uniform across
  93. the installation.
  94. .(l
  95. .ft C
  96. Usage: pagedoc [-h|b|r] [-d level] filename
  97. .ft P
  98. .)l
  99. -h, -b, and -r are for heap, btree, and rtree files, respectively.
  100. -d level sets the detail level:
  101. .(l
  102. 0 - page summaries.
  103. 1 - page summaries and line pointer summaries.
  104. 2 - all of 1 plus information about each tuple.
  105. .)l
  106. -h and -d0 are the defaults.
  107. .sh 2 "shmemdoc"
  108. .pp
  109. Shmemdoc is a shared memory doctor program.  
  110. It allows you to view the state of shared memory and
  111. semaphores after an abnormal termination (i.e. a backend crash).
  112. It assumes that
  113. state is static -- that is, no other process should be changing
  114. shared memory while shmemdoc is running.  In order to use this,
  115. you should start the postmaster with the -n option (no reinitialization)
  116. in order to avoid reinitializing shared structures after a backend
  117. terminates abnormally.  For information on the available commands
  118. type 'help' at the shmemdoc prompt.
  119. .sh 1 "Known Bugs"
  120. .pp
  121. There are a few known bugs that we did not fix in this release.  
  122. .sh 2 "Asynchronous Portals"
  123. .pp
  124. A flaw in the implementation of asynchronous portals was discovered a
  125. day or so before shipping 4.0.1.  Notifies were handled via signals,
  126. and processing them asynchronously can lead to a variety of problems.
  127. A cleaner implementation has been conceived, but there was no way to
  128. do it for this release.  For this reason async portals have been backed
  129. out of the system.  The cleaner version will be ready by the next release.
  130. .sh 2 "Hash Joins"
  131. .pp
  132. The current implementation of hash joins in \*(PG attempts to put the
  133. entire hash table in virtual memory.  If the hash table is too big
  134. to fit into memory the transaction will be aborted.  The planner tries
  135. to take relation size into account when deciding whether or not to
  136. plan a hash join, but it is dependent on the most recent database
  137. statistics.  If these are out of date \*(PG might still exhibit
  138. this unfriendly behavior.  To avoid this problem you should vacuum your
  139. database after any and all large append/copy commands.
  140. .sh 2 "ISNULL/NOTNULL and Index Scans"
  141. .pp
  142. Query qualifications based on null detection will cause a crash if there
  143. is an index defined on that attribute.  One specific example is as follows:
  144. .(l
  145. .ft C
  146. create foo (a = int4) \eg
  147. define index fooind on foo using btree (a int4_ops) \eg
  148. retrieve (foo.all) where foo.a ISNULL \eg
  149. .ft P
  150. .)l
  151. .sh 2 "Cache Invalidation"
  152. .pp
  153. There is a subtle bug relating to cache invalidation that can cause \*(PG
  154. to violate transaction semantics in transactions/queries involving multiple
  155. commands.  If the backend has a relation open that needs to be invalidated
  156. when one command is finished the invalidation message is ignored.  Thus
  157. the relation descriptor can become out of date, and won't be updated until the
  158. next time it is invalidated.   At the time of writing we believe that
  159. the odds you will ever notice this bug are small.
  160. .sh 2 "Define Operator"
  161. .pp
  162. At the very last moment we discovered that you cannot successfully declare
  163. the commutator and/or negator of an operator if they are not already defined.
  164. This makes it tricky to define an operator class to allow index scans over
  165. a user defined data type.  You have to do define all the operators in the
  166. operator class, and then update the negator and commutator fields by hand
  167. (i.e. using the terminal monitor).
  168. .sh 2 "Set Functions and Instance Rules"
  169. .pp
  170. The instance level rule system requires the ability to convert an arbitrary
  171. plan into its string equivalent, as well as the ability to convert the
  172. string representation back to a valid plan tree.  There were two new plan
  173. nodes added to the system for the implementation of postquel functions
  174. returning sets of results.  The string to plan conversion functions do not
  175. know about these nodes and therefore cannot convert them.  For this reason
  176. you cannot have such functions in the body of an instance level rule.  You
  177. have to use rewrite rules.
  178. .sh 2 "Versions"
  179. .pp
  180. Currently, a replace to a version causes the new tuple to appear twice in
  181. subsequent retrieves.
  182. .sh 2 "Installation and Awk"
  183. .pp
  184. The awk scripts \*(PG uses during the installation will not work with
  185. various language versions of awk.  Be sure to use the standard unix
  186. awk utility.
  187. .sh 2 "Indices and the Instance Level Rule System"
  188. .pp
  189. As ever, the Instance Level Rule System essentially ignores indices, so if
  190. you are
  191. defining a rule on an indexed attribute, you should use the Query Rewrite
  192. rule system.
  193. .sh 2 "Retrieve Into and failed backends"
  194. .pp
  195. If a backend fails while in the course of executing a Retrieve Into query,
  196. a spurious file, with the same name as the target class of the Retrieve Into,
  197. will be left in the database directory.  This file can be safely deleted by the
  198. database DBA. 
  199. .sh 2 "Large Objects and failed backends"
  200. .pp
  201. If a backend fails while it is manipulating large objects, spurious large
  202. object files will be left in the database directory.  Also, there is no
  203. mechanism for getting rid of large objects which are returned by functions
  204. but not stored in instances.
  205. .sh 1 "Known bugs list"
  206. .pp
  207. A list of known bugs and suggested work-arounds can be anonymously
  208. ftp'ed.  This list is kept in the file ~ftp/pub/postgres-v4r0r1.bugs.
  209. We will make every attempt to keep this list up to date.
  210. .sh 1 "Machine-dependent Problems"
  211. .pp
  212. .sh 2 "Sparcstations running SunOS 4.0.3"
  213. .pp
  214. Postgres has been known to crash SunOS 4.0.3 on Sparcstations, due to a SunOS
  215. bug in shared memory.  It appears to work on SunOS 4.1 and higher, so any
  216. reports of crashes on SunOS 4.1 and higher are appreciated.
  217.