Skip to content

Commit 6858f31

Browse files
author
hackorum
committed
Apply adv_lock_limit.diff
1 parent 9e7d152 commit 6858f31

1 file changed

Lines changed: 13 additions & 10 deletions

File tree

‎doc/src/sgml/mvcc.sgml‎

Lines changed: 13 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -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 &gt; 12345 LIMIT 100; -- danger!
1647-
SELECT pg_advisory_lock(q.id) FROM
1648-
(
1649-
SELECT id FROM foo WHERE id &gt; 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 &gt; 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 &gt; 12345 LIMIT 100
1661+
) q; -- ok
1662+
</screen>
16601663
</para>
16611664

16621665
<para>

0 commit comments

Comments
 (0)