Notes in Migration to v6.5 section.

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 2ce81ace1ac2b711d7e6192a39a91fab286f560b..cf4c8a92b8784307ef5ecce0f219845ce39f1638 100644 (file)
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -515,7 +515,7 @@ ERROR:  Can't serialize access due to concurrent update
     by SELECT it doesn't mean that this row really
     exists at the time it is returned (i.e. sometime after the
     statement or transaction began) nor
-    that the row is protected from deletion or update by concurrent
+    that the row is protected from deletion or updation by concurrent
     transactions before the current transaction does a commit or rollback. 
    
 

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index e3071b2f6e65b863f99e7c54808db8993d26c34e..f8718c4aaca2113eb1ebad3491dd079be32b1303 100644 (file)
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -132,11 +132,65 @@
      is required for those wishing to migrate data from any
      previous release of Postgres.
     
-   
+
+    
+
+     Because readers in 6.5 don't lock data, regardless of transaction
+     isolation level, data read by one transaction can be overwritten by
+     another. In the other words, if a row is returned by
+     SELECT it doesn't mean that this row really exists
+     at the time it is returned (i.e. sometime after the statement or
+     transaction began) nor that the row is protected from deletion or
+     updation by concurrent transactions before the current transaction does
+     a commit or rollback.
+
+    
+
+    
+
+     To ensure the actual existance of a row and protect it against
+     concurrent updates one must use SELECT FOR UPDATE or
+     an appropriate LOCK TABLE statement. This should be
+     taken into account when porting applications from previous releases of
+     Postgres and other environments.
+
+    
+
+    
+
+     Keep above in mind if you are using contrib/refint.* triggers for
+     referential integrity. Additional technics are required now. One way is
+     to use LOCK parent_table IN SHARE ROW EXCLUSIVE MODE
+     command if a transaction is going to update/delete a primary key and
+     use LOCK parent_table IN SHARE MODE command if a
+     transaction is going to update/insert a foreign key.
+
+        
+        
+
+     Note that if you run a transaction in SERIALIZABLE mode then you must
+     execute LOCK commands above before execution of any
+     DML statement
+     (SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO) in the
+     transaction.
+
+        
+        
+
+        
+
+     These inconveniences will disappear when the ability to read durty
+     (uncommitted) data, regardless of isolation level, and true referential
+     integrity will be implemented.
+
+        
+
+    
+
+    
 
    
     Detailed Change List
-
     
      
 Bug Fixes