diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 2ba89b413ae..acc0b9d2024 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -70,12 +70,12 @@ Branch: REL9_3_STABLE [8e9a16ab8] 2013-12-16 11:29:51 -0300
      </para>
 
      <para>
-      Fixing this required changing the WAL logging format for tuple freezing.
-      While this is unimportant for standalone servers, in replication
-      environments it means that <emphasis>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 <emphasis>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.)
      </para>
     </listitem>
@@ -121,16 +121,16 @@ Branch: REL9_3_STABLE [db1014bc4] 2013-12-18 13:31:27 -0300
      <para>
       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.
      </para>
 
      <para>
       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 <literal>SELECT FOR KEY SHARE</>
       and <literal>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 <quote>forgetting</> valid row locks when one of several
       holders of a row lock aborts (&Aacute;lvaro Herrera)
      </para>
+
+     <para>
+      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.
+     </para>
     </listitem>
 
 <!--
@@ -169,6 +175,20 @@ Branch: REL9_3_STABLE [2dcc48c35] 2013-12-05 17:47:51 -0300
      </para>
     </listitem>
 
+<!--
+Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master [a50d97625] 2014-01-02 18:17:07 -0300
+Branch: REL9_3_STABLE [03db79459] 2014-01-02 18:17:07 -0300
+-->
+
+    <listitem>
+     <para>
+      Handle wraparound correctly during extension or truncation
+      of <filename>pg_multixact/members</>
+      (Andres Freund, &Aacute;lvaro Herrera)
+     </para>
+    </listitem>
+
 <!--
 Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
 Branch: master [638cf09e7] 2014-01-02 18:17:29 -0300
@@ -187,20 +207,6 @@ Branch: REL9_3_STABLE [948a3dfbb] 2014-01-02 18:17:29 -0300
      </para>
     </listitem>
 
-<!--
-Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
-Branch: master [a50d97625] 2014-01-02 18:17:07 -0300
-Branch: REL9_3_STABLE [03db79459] 2014-01-02 18:17:07 -0300
--->
-
-    <listitem>
-     <para>
-      Handle wraparound correctly during extension or truncation
-      of <filename>pg_multixact/members</>
-      (Andres Freund, &Aacute;lvaro Herrera)
-     </para>
-    </listitem>
-
 <!--
 Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
 Branch: master [d881dd623] 2013-12-13 17:16:25 -0300
@@ -246,9 +252,9 @@ Branch: REL9_3_STABLE [762bd379a] 2014-02-14 15:18:34 +0200
      </para>
 
      <para>
-      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.
      </para>
     </listitem>
 
@@ -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.
      </para>
     </listitem>
 
@@ -298,9 +304,9 @@ Branch: REL9_0_STABLE [5301c8395] 2014-01-08 14:34:21 +0200
      <para>
       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 <quote>PANIC: WAL contains references to invalid pages</>
-      were also possible.
+      hot-standby queries before the database was really consistent.  Other
+      symptoms such as <quote>PANIC: WAL contains references to invalid
+      pages</> were also possible.
      </para>
     </listitem>
 
@@ -328,7 +334,7 @@ Branch: REL9_0_STABLE [5d742b9ce] 2014-01-14 17:35:00 -0500
     <listitem>
      <para>
       Fix improper locking of btree index pages while replaying
-      a <literal>VACUUM</> operation in Hot Standby mode (Andres Freund,
+      a <literal>VACUUM</> operation in hot-standby mode (Andres Freund,
       Heikki Linnakangas, Tom Lane)
      </para>
 
@@ -350,13 +356,13 @@ Branch: REL8_4_STABLE [67fc33d3a] 2013-12-03 22:53:26 +0200
 
     <listitem>
      <para>
-      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)
      </para>
 
      <para>
-      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.
      </para>
     </listitem>
 
@@ -385,7 +391,7 @@ Branch: REL9_3_STABLE [e34acac62] 2014-01-16 23:14:57 +0200
 
     <listitem>
      <para>
-      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)
      </para>
@@ -461,7 +467,7 @@ Branch: REL8_4_STABLE [01b882fd8] 2014-01-29 20:04:14 -0500
 
     <listitem>
      <para>
-      Fix unsafe references to <varname>errno</> within error messaging
+      Fix unsafe references to <varname>errno</> within error reporting
       logic (Christian Kruse)
      </para>
 
@@ -505,13 +511,13 @@ Branch: REL8_4_STABLE [7635dae55] 2013-12-05 12:48:44 -0500
 
     <listitem>
      <para>
-      Clear retry flags properly in replacement OpenSSL socket write
+      Clear retry flags properly in OpenSSL socket write
       function (Alexander Kukushkin)
      </para>
 
      <para>
-      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.
      </para>
     </listitem>
 
@@ -695,7 +701,7 @@ Branch: REL8_4_STABLE [00b77771a] 2014-01-11 13:42:11 -0500
 
      <para>
       <command>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.
      </para>
     </listitem>
@@ -718,8 +724,8 @@ Branch: REL8_4_STABLE [0fb4e3ceb] 2014-01-18 18:50:47 -0500
      </para>
 
      <para>
-      <literal>CREATE TABLE</> works this way, but <literal>ALTER TABLE</>
-      didn't get the memo.
+      <literal>CREATE TABLE</> has always allowed such usage,
+      but <literal>ALTER TABLE</> didn't get the memo.
      </para>
     </listitem>
 
@@ -747,8 +753,8 @@ Branch: REL8_4_STABLE [57ac7d8a7] 2014-01-08 20:18:24 -0500
 
     <listitem>
      <para>
-      Fix <quote>cannot accept a set</> error when some arms of a CASE
-      return a set and others don't (Tom Lane)
+      Fix <quote>cannot accept a set</> error when some arms of
+      a <literal>CASE</> return a set and others don't (Tom Lane)
      </para>
     </listitem>
 
@@ -873,7 +879,7 @@ Branch: REL8_4_STABLE [69f77d756] 2013-12-15 11:11:11 +0900
     <listitem>
      <para>
       Accept <literal>SHIFT_JIS</> as an encoding name for locale checking
-      (Tatsuo Ishii)
+      purposes (Tatsuo Ishii)
      </para>
     </listitem>
 
@@ -929,7 +935,7 @@ Branch: REL8_4_STABLE [7644a7bd8] 2014-02-13 18:45:32 -0500
 
     <listitem>
      <para>
-      Improve error handling in <application>psql</> and <application>libpq</>
+      Improve error handling in <application>libpq</> and <application>psql</>
       for failures during <literal>COPY TO STDOUT/FROM STDIN</> (Tom Lane)
      </para>
 
@@ -959,21 +965,6 @@ Branch: REL9_2_STABLE [fa28f9cba] 2014-01-04 16:05:23 -0500
      </para>
     </listitem>
 
-<!--
-Author: Magnus Hagander <magnus@hagander.net>
-Branch: master [b168c5ef2] 2014-01-07 17:11:32 +0100
-Branch: REL9_3_STABLE [0463b9419] 2014-01-07 17:11:51 +0100
-Branch: REL9_2_STABLE [2edf3e82c] 2014-01-07 17:22:36 +0100
-Branch: REL9_1_STABLE [773e4d5e4] 2014-01-07 17:18:02 +0100
--->
-
-    <listitem>
-     <para>
-      Avoid including tablespaces inside PGDATA twice in base backups
-      (Dimitri Fontaine, Magnus Hagander)
-     </para>
-    </listitem>
-
 <!--
 Author: Magnus Hagander <magnus@hagander.net>
 Branch: master [63ab2befe] 2014-02-12 18:45:18 +0100
@@ -1003,6 +994,21 @@ Branch: REL9_1_STABLE [c6e5c4dd1] 2014-02-09 12:09:55 +0100
      </para>
     </listitem>
 
+<!--
+Author: Magnus Hagander <magnus@hagander.net>
+Branch: master [b168c5ef2] 2014-01-07 17:11:32 +0100
+Branch: REL9_3_STABLE [0463b9419] 2014-01-07 17:11:51 +0100
+Branch: REL9_2_STABLE [2edf3e82c] 2014-01-07 17:22:36 +0100
+Branch: REL9_1_STABLE [773e4d5e4] 2014-01-07 17:18:02 +0100
+-->
+
+    <listitem>
+     <para>
+      Avoid including tablespaces inside PGDATA twice in base backups
+      (Dimitri Fontaine, Magnus Hagander)
+     </para>
+    </listitem>
+
 <!--
 Author: Michael Meskes <meskes@postgresql.org>
 Branch: master [d685e2424] 2014-01-09 16:20:19 +0100
@@ -1049,7 +1055,7 @@ Branch: REL8_4_STABLE [6c8b16e30] 2013-12-07 16:56:34 -0800
     <listitem>
      <para>
       Fix performance regression in <filename>contrib/dblink</> connection
-      setup (Joe Conway)
+      startup (Joe Conway)
      </para>
 
      <para>
@@ -1132,22 +1138,6 @@ Branch: REL8_4_STABLE [15699d9bf] 2014-01-17 23:17:59 -0500
      </para>
     </listitem>
 
-<!--
-Author: Andrew Dunstan <andrew@dunslane.net>
-Branch: master [7e1531a45] 2014-02-01 16:08:33 -0500
-Branch: REL9_3_STABLE [27942baf4] 2014-02-01 16:13:32 -0500
-Branch: REL9_2_STABLE [fad443753] 2014-02-01 16:13:46 -0500
-Branch: REL9_1_STABLE [e5c22c15d] 2014-02-01 16:14:01 -0500
-Branch: REL9_0_STABLE [1c0bf372f] 2014-02-01 16:14:15 -0500
--->
-
-    <listitem>
-     <para>
-      Avoid using the deprecated <literal>dllwrap</> tool in Cygwin builds
-      (Marco Atzeri)
-     </para>
-    </listitem>
-
 <!--
 Author: Andrew Dunstan <andrew@dunslane.net>
 Branch: master [d587298b8] 2014-02-01 15:11:13 -0500
@@ -1171,6 +1161,22 @@ Branch: REL8_4_STABLE [ae3c98b9b] 2014-02-01 15:16:52 -0500
      </para>
     </listitem>
 
+<!--
+Author: Andrew Dunstan <andrew@dunslane.net>
+Branch: master [7e1531a45] 2014-02-01 16:08:33 -0500
+Branch: REL9_3_STABLE [27942baf4] 2014-02-01 16:13:32 -0500
+Branch: REL9_2_STABLE [fad443753] 2014-02-01 16:13:46 -0500
+Branch: REL9_1_STABLE [e5c22c15d] 2014-02-01 16:14:01 -0500
+Branch: REL9_0_STABLE [1c0bf372f] 2014-02-01 16:14:15 -0500
+-->
+
+    <listitem>
+     <para>
+      Avoid using the deprecated <literal>dllwrap</> tool in Cygwin builds
+      (Marco Atzeri)
+     </para>
+    </listitem>
+
 <!--
 Author: Andrew Dunstan <andrew@dunslane.net>
 Branch: master [cec8394b5] 2014-01-26 09:49:10 -0500
@@ -1202,11 +1208,11 @@ Branch: REL8_4_STABLE [432735cbf] 2014-02-10 20:48:30 -0500
      <para>
       These text files duplicated the main HTML and PDF documentation
       formats.  The trouble involved in maintaining them greatly outweighs
-      the likely audience for this format.  Distribution tarballs will
-      still contain files by these names, but they'll just be stubs
+      the likely audience for plain-text format.  Distribution tarballs
+      will still contain files by these names, but they'll just be stubs
       directing the reader to consult the main documentation.
       The plain-text <filename>INSTALL</> file will still be maintained, as
-      there is arguably an audience for that.
+      there is arguably a use-case for that.
      </para>
     </listitem>
 
@@ -1227,9 +1233,10 @@ Branch: REL8_4_STABLE [c0c2d62ac] 2014-02-14 21:59:56 -0500
      </para>
 
      <para>
-      In addition, the zones Asia/Riyadh87, Asia/Riyadh88, and
-      Asia/Riyadh89 have been removed, as they are no longer maintained by
-      IANA, and never represented actual civil timekeeping practice.
+      In addition, the zones <literal>Asia/Riyadh87</>,
+      <literal>Asia/Riyadh88</>, and <literal>Asia/Riyadh89</> have been
+      removed, as they are no longer maintained by IANA, and never
+      represented actual civil timekeeping practice.
      </para>
     </listitem>