Document that SELECT ... ORDER BY .. FOR UPDATE/SHARE might return

results out of order because of locking, per bug report 4593

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 5cedb1cf3186da1ad1ae22108abc67c91155870b..a33a537bd484d5bc0e5c076fae1c31e16d4f5e51 100644 (file)
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1,5 +1,5 @@
 
 
@@ -1163,16 +1163,31 @@ ROLLBACK TO s;
   
    
     It is possible for a SELECT command using both
-    LIMIT and  FOR UPDATE/SHARE
+    LIMIT and FOR UPDATE/SHARE
     clauses to return fewer rows than specified by LIMIT.
     This is because LIMIT is applied first.  The command
     selects the specified number of rows,
-    but might then block trying to obtain lock on one or more of them.
+    but might then block trying to obtain a lock on one or more of them.
     Once the SELECT unblocks, the row might have been deleted
     or updated so that it does not meet the query WHERE condition
     anymore, in which case it will not be returned.
    
   
+
+  
+   
+    Similarly, it is possible for a SELECT command
+    using ORDER BY and FOR
+    UPDATE/SHARE to return rows out of order.  This is
+    because ORDER BY is applied first.  The command
+    orders the result, but might then block trying to obtain a lock
+    on one or more of the rows.  Once the SELECT
+    unblocks, one of the ordered columns might have been modified
+    and be returned out of order.  A workaround is to perform
+    SELECT ... FOR UPDATE/SHARE and then SELECT
+    ... ORDER BY.
+   
+