@@ -1640,23 +1640,26 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
16401640 In certain cases using advisory locking methods, especially in queries
16411641 involving explicit ordering and <literal>LIMIT</literal> clauses, care must be
16421642 taken to control the locks acquired because of the order in which SQL
1643- expressions are evaluated. For example:
1644- <screen>
1645- SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
1646- SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger!
1647- SELECT pg_advisory_lock(q.id) FROM
1648- (
1649- SELECT id FROM foo WHERE id > 12345 LIMIT 100
1650- ) q; -- ok
1651- </screen>
1652- In the above queries, the second form is dangerous because the
1643+ expressions are evaluated. For example,
1644+ this query is dangerous because the
16531645 <literal>LIMIT</literal> is not guaranteed to be applied before the locking
16541646 function is executed. This might cause some locks to be acquired
16551647 that the application was not expecting, and hence would fail to release
16561648 (until it ends the session).
16571649 From the point of view of the application, such locks
16581650 would be dangling, although still viewable in
16591651 <structname>pg_locks</structname>.
1652+ <screen>
1653+ SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger!
1654+ </screen>
1655+ The below forms are safe:
1656+ <screen>
1657+ SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
1658+ SELECT pg_advisory_lock(q.id) FROM
1659+ (
1660+ SELECT id FROM foo WHERE id > 12345 LIMIT 100
1661+ ) q; -- ok
1662+ </screen>
16601663 </para>
16611664
16621665 <para>
0 commit comments