postgres.git / summary / log / commit / refs

commit    9cf12dfd4e9e5301d7f8cf48e1eead1626c42127
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Fri Oct 28 16:02:04 2011 +0000
First released in: 9.2.0, 9.1.2

    Clarify that ORDER BY/FOR UPDATE can't malfunction at higher iso levels.
    
    Kevin Grittner


 doc/src/sgml/ref/select.sgml | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 636435fe1d8..cc8cd48583a 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1281,7 +1281,8 @@ ROLLBACK TO s;
 
   <caution>
    <para>
-    It is possible for a <command>SELECT</> command using <literal>ORDER
+    It is possible for a <command>SELECT</> command running at the <literal>READ
+    COMMITTED</literal> transaction isolation level and using <literal>ORDER
     BY</literal> and <literal>FOR UPDATE/SHARE</literal> to return rows out of
     order.  This is because <literal>ORDER BY</> is applied first.
     The command sorts the result, but might then block trying to obtain a lock
@@ -1302,6 +1303,13 @@ SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;
     only if concurrent updates of the ordering columns are expected and a
     strictly sorted result is required.
    </para>
+
+   <para>
+    At the <literal>REPEATABLE READ</literal> or <literal>SERIALIZABLE</literal>
+    transaction isolation level this would cause a serialization failure (with
+    a <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is
+    no possibility of receiving rows out of order under these isolation levels.
+   </para>
   </caution>
   </refsect2>
 


[parent: 6c21105fb40a]