FOR UPDATE may leave spurious locks

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: FOR UPDATE may leave spurious locks
Date: 2022-11-22 07:23:23
Message-ID: 20221122.162323.661294930832855238.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

I noticed that $SUBJECT. "spurious" here means the locks on the rows
that are not seemingly qualified by the query condition (that is, EPQ
failure).

It doesn't seem to be a bug to me (or it
seems just inevitable.). But that doesn't seems to be described either
in the doc. If I'm right here, don't we need one, something like this?

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 1f9538f2fe..97253dedc6 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -200,6 +200,9 @@ TABLE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ]
<command>SELECT</command> statement locks the selected rows
against concurrent updates. (See <xref linkend="sql-for-update-share"/>
below.)
+ Note that concurrent udpates may cause some unmatched rows locked.
+ SELECT statements with SKIP LOCKED may miss some rows that are not
+ returned by concurrent FOR_UPDATE queries.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2022-11-22 07:25:36 RE: wake up logical workers after ALTER SUBSCRIPTION
Previous Message Takamichi Osumi (Fujitsu) 2022-11-22 07:18:40 RE: wake up logical workers after ALTER SUBSCRIPTION