select-order-by-caution.patch

text/plain

Filename: select-order-by-caution.patch

Type: text/plain

Part: 0

Patch

Same data as JSON: GET /api/v1/attachments/:id/patch the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes. API reference →

Format: context

File	+	−
doc/src/sgml/ref/select.sgml	9	0

*** a/doc/src/sgml/ref/select.sgml
--- b/doc/src/sgml/ref/select.sgml
***************
*** 1281,1287 **** ROLLBACK TO s;
  
    <caution>
     <para>
!     It is possible for a <command>SELECT</> command 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
--- 1281,1288 ----
  
    <caution>
     <para>
!     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,1307 **** SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;
--- 1303,1315 ----
      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>