sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-31 00:01:57 -04:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
Kevin Grittner
This commit is contained in:
Robert Haas 2011-10-28 12:02:04 -04:00
parent 6c21105fb4
commit 9cf12dfd4e
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/sgml/ref/select.sgml
View File

@ -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>