From 734ff84b086e098e6106f19c4146357c5eaa9594 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 16 Feb 2014 14:54:28 -0500 Subject: [PATCH] Further wordsmithing on 9.3.3 release notes. No substantive changes, but reorder some items and improve some descriptions. --- doc/src/sgml/release-9.3.sgml | 179 ++++++++++++++++++---------------- 1 file changed, 93 insertions(+), 86 deletions(-) diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml index 2ba89b413a..acc0b9d202 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. + + + + + 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) - - - - - - - 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) + + +