Commitaf0cc0f

committed

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

Kevin Grittner

1 parente489c00 commitaf0cc0fCopy full SHA for af0cc0f

File tree

-1

lines changed

-1

lines changed

Lines changed: 9 additions & 1 deletion

Original file line number	Diff line number	Diff line change
`@@ -1280,7 +1280,8 @@ ROLLBACK TO s;`
`1280`	`1280`
`1281`	`1281`	`<caution>`
`1282`	`1282`	`<para>`
`1283`		`- It is possible for a <command>SELECT</> command using <literal>ORDER`
	`1283`	`+ It is possible for a <command>SELECT</> command running at the <literal>READ`
	`1284`	`+ COMMITTED</literal> transaction isolation level and using <literal>ORDER`
`1284`	`1285`	`BY</literal> and <literal>FOR UPDATE/SHARE</literal> to return rows out of`
`1285`	`1286`	`order. This is because <literal>ORDER BY</> is applied first.`
`1286`	`1287`	`The command sorts the result, but might then block trying to obtain a lock`
`@@ -1301,6 +1302,13 @@ SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;`
`1301`	`1302`	`only if concurrent updates of the ordering columns are expected and a`
`1302`	`1303`	`strictly sorted result is required.`
`1303`	`1304`	`</para>`
	`1305`	`+`
	`1306`	`+ <para>`
	`1307`	`+ At the <literal>REPEATABLE READ</literal> or <literal>SERIALIZABLE</literal>`
	`1308`	`+ transaction isolation level this would cause a serialization failure (with`
	`1309`	`+ a <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is`
	`1310`	`+ no possibility of receiving rows out of order under these isolation levels.`
	`1311`	`+ </para>`
`1304`	`1312`	`</caution>`
`1305`	`1313`	`</refsect2>`
`1306`	`1314`

Comments

(0)