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
- 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
+ a 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)
+
+
+