Thread: FOR UPDATE may leave spurious locks

FOR UPDATE may leave spurious locks

From
Kyotaro Horiguchi
Date:
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