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