Further wordsmithing on 9.3.3 release notes.
authorTom Lane
Sun, 16 Feb 2014 19:54:28 +0000 (14:54 -0500)
committerTom Lane
Sun, 16 Feb 2014 19:54:28 +0000 (14:54 -0500)
No substantive changes, but reorder some items and improve some
descriptions.

doc/src/sgml/release-9.3.sgml

index 2ba89b413ae440784c1cf30fbcf74c5234c3370f..acc0b9d2024a5bf5a9f0023c683e9ae49217b11e 100644 (file)
@@ -70,12 +70,12 @@ Branch: REL9_3_STABLE [8e9a16ab8] 2013-12-16 11:29:51 -0300
      
 
      
-      Fixing this required changing the WAL logging format for tuple freezing.
-      While this is unimportant for standalone servers, in replication
-      environments it means that standby servers must be upgraded
+      Fixing this required changing the WAL record format for tuple
+      freezing.  While this is no issue for standalone servers, when using
+      replication it means that standby servers must be upgraded
       to 9.3.3 or later before their masters are.  An older standby will
-      be unable to interpret freeze records generated by a newer master,
-      and will fail with a PANIC message.  (In such a case, upgrading the
+      be unable to interpret freeze records generated by a newer master, and
+      will fail with a PANIC message.  (In such a case, upgrading the
       standby should be sufficient to let it resume execution.)
      
     
@@ -121,16 +121,16 @@ Branch: REL9_3_STABLE [db1014bc4] 2013-12-18 13:31:27 -0300
      
       If a row was locked by transaction A, and transaction B updated it,
       the new version of the row created by B would be locked by A, yet
-      visible only to B.  This case is new in 9.3 since prior versions did
-      not have any types of row locking that would permit another
-      transaction to update the row at all.  If transaction B then deleted
-      or key-updated the row, A's lock wouldn't get checked, thus possibly
-      allowing B to complete when it shouldn't.
+      visible only to B.  If transaction B then again updated the row, A's
+      lock wouldn't get checked, thus possibly allowing B to complete when
+      it shouldn't.  This case is new in 9.3 since prior versions did not
+      have any types of row locking that would permit another transaction
+      to update the row at all.
      
 
      
       This oversight could allow referential integrity checks to give false
-      positives (that is, allow deletes that should have been rejected).
+      positives (for instance, allow deletes that should have been rejected).
       Applications using the new commands SELECT FOR KEY SHARE
       and SELECT FOR NO KEY UPDATE might also have suffered
       locking failures of this kind.
@@ -148,6 +148,12 @@ Branch: REL9_3_STABLE [c6cd27e36] 2013-12-05 12:21:55 -0300
       Prevent forgetting valid row locks when one of several
       holders of a row lock aborts (Álvaro Herrera)
      
+
+     
+      This was yet another mechanism by which a shared row lock could be
+      lost, thus possibly allowing updates that should have been prevented
+      by foreign-key constraints.
+     
     
 
 
 
     
      
-      Fix handling of 5-digit filenames in pg_multixact/members
-      (Álvaro Herrera)
-     
-
-     
-      As of 9.3, these names can be more than 4 digits, but the directory
-      cleanup code ignored such files.
+      Handle wraparound correctly during extension or truncation
+      of pg_multixact/members
+      (Andres Freund, Álvaro Herrera)
      
     
 
 
 
     
      
-      Handle wraparound correctly during extension or truncation
-      of pg_multixact/members
-      (Andres Freund, Álvaro Herrera)
+      Fix handling of 5-digit filenames in pg_multixact/members
+      (Álvaro Herrera)
+     
+
+     
+      As of 9.3, these names can be more than 4 digits, but the directory
+      cleanup code ignored such files.
      
     
 
@@ -246,9 +252,9 @@ Branch: REL9_3_STABLE [762bd379a] 2014-02-14 15:18:34 +0200
      
 
      
-      Previously, not-yet-archived segments could get ignored during replay.
-      This reverts an undesirable behavioral change in 9.3.0 back to the
-      way things worked pre-9.3.
+      Previously, not-yet-archived segments could get ignored during
+      recovery.  This reverts an undesirable behavioral change in 9.3.0
+      back to the way things worked pre-9.3.
      
     
 
@@ -276,7 +282,7 @@ Branch: REL8_4_STABLE [9620fede9] 2014-02-12 14:52:32 -0500
       applied far beyond where the end-of-file should have been.  This
       failure mode does not appear to be a significant risk during crash
       recovery, only when initially synchronizing a standby created from a
-      base backup taken from an actively-changing master.
+      base backup taken from a quickly-changing master.
      
     
 
@@ -298,9 +304,9 @@ Branch: REL9_0_STABLE [5301c8395] 2014-01-08 14:34:21 +0200
      
       In some cases WAL replay would mistakenly conclude that the database
       was already consistent at the start of replay, thus possibly allowing
-      queries before the database was really consistent.  Other symptoms
-      such as PANIC: WAL contains references to invalid pages
-      were also possible.
+      hot-standby queries before the database was really consistent.  Other
+      symptoms such as PANIC: WAL contains references to invalid
+      pages were also possible.
      
     
 
@@ -328,7 +334,7 @@ Branch: REL9_0_STABLE [5d742b9ce] 2014-01-14 17:35:00 -0500
     
      
       Fix improper locking of btree index pages while replaying
-      a VACUUM operation in Hot Standby mode (Andres Freund,
+      a VACUUM operation in hot-standby mode (Andres Freund,
       Heikki Linnakangas, Tom Lane)
      
 
@@ -350,13 +356,13 @@ Branch: REL8_4_STABLE [67fc33d3a] 2013-12-03 22:53:26 +0200
 
     
      
-      Ensure that insertions into non-leaf GIN index pages make a full-page
+      Ensure that insertions into non-leaf GIN index pages write a full-page
       WAL record when appropriate (Heikki Linnakangas)
      
 
      
-      The previous coding risked data corruption in the event of a
-      torn-page update.
+      The previous coding risked index corruption in the event of a
+      partial-page write during a system crash.
      
     
 
@@ -385,7 +391,7 @@ Branch: REL9_3_STABLE [e34acac62] 2014-01-16 23:14:57 +0200
 
     
      
-      Ensure walreceiver sends Hot Standby feedback messages on time even
+      Ensure walreceiver sends hot-standby feedback messages on time even
       when there is a continuous stream of data (Andres Freund, Amit
       Kapila)
      
@@ -461,7 +467,7 @@ Branch: REL8_4_STABLE [01b882fd8] 2014-01-29 20:04:14 -0500
 
     
      
-      Fix unsafe references to errno within error messaging
+      Fix unsafe references to errno within error reporting
       logic (Christian Kruse)
      
 
@@ -505,13 +511,13 @@ Branch: REL8_4_STABLE [7635dae55] 2013-12-05 12:48:44 -0500
 
     
      
-      Clear retry flags properly in replacement OpenSSL socket write
+      Clear retry flags properly in OpenSSL socket write
       function (Alexander Kukushkin)
      
 
      
-      This omission resulted in a server lockup after unexpected loss of an
-      SSL-encrypted connection.
+      This omission could result in a server lockup after unexpected loss
+      of an SSL-encrypted connection.
      
     
 
@@ -695,7 +701,7 @@ Branch: REL8_4_STABLE [00b77771a] 2014-01-11 13:42:11 -0500
 
      
       ANALYZE intentionally omits very wide values from its
-      histogram and most-common-value calculations, but it neglected to do
+      histogram and most-common-values calculations, but it neglected to do
       something sane in the case that all the sampled entries are too wide.
      
     
@@ -718,8 +724,8 @@ Branch: REL8_4_STABLE [0fb4e3ceb] 2014-01-18 18:50:47 -0500
      
 
      
-      CREATE TABLE works this way, but ALTER TABLE
-      didn't get the memo.
+      CREATE TABLE has always allowed such usage,
+      but ALTER TABLE didn't get the memo.
      
     
 
@@ -747,8 +753,8 @@ Branch: REL8_4_STABLE [57ac7d8a7] 2014-01-08 20:18:24 -0500
 
     
      
-      Fix cannot accept a set error when some arms of a CASE
-      return a set and others don't (Tom Lane)
+      Fix cannot accept a set error when some arms of
+      CASE return a set and others don't (Tom Lane)
      
     
 
@@ -873,7 +879,7 @@ Branch: REL8_4_STABLE [69f77d756] 2013-12-15 11:11:11 +0900
     
      
       Accept SHIFT_JIS as an encoding name for locale checking
-      (Tatsuo Ishii)
+      purposes (Tatsuo Ishii)
      
     
 
@@ -929,7 +935,7 @@ Branch: REL8_4_STABLE [7644a7bd8] 2014-02-13 18:45:32 -0500
 
     
      
-      Improve error handling in psql and libpq
+      Improve error handling in libpq and psql
       for failures during COPY TO STDOUT/FROM STDIN (Tom Lane)
      
 
@@ -959,21 +965,6 @@ Branch: REL9_2_STABLE [fa28f9cba] 2014-01-04 16:05:23 -0500
      
     
 
-
-
-    
-     
-      Avoid including tablespaces inside PGDATA twice in base backups
-      (Dimitri Fontaine, Magnus Hagander)
-     
-    
-
 
+
+    
+     
+      Avoid including tablespaces inside PGDATA twice in base backups
+      (Dimitri Fontaine, Magnus Hagander)
+     
+    
+
 
-
-    
-     
-      Avoid using the deprecated dllwrap tool in Cygwin builds
-      (Marco Atzeri)
-     
-    
-
 
+
+    
+     
+      Avoid using the deprecated dllwrap tool in Cygwin builds
+      (Marco Atzeri)
+     
+    
+