From: David Christensen <david@endpoint.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
Date: Wed, 21 Oct 2020 14:12:29 -0500
Message-ID: <E75ECBBA-5902-4598-8F09-F36192E184EE@endpoint.com> (raw)
In-Reply-To: <7EA65D44-7C3A-4FC2-8DE1-1F59BBB10B37@endpoint.com>
References: <7B98FC76-00EE-4441-AF10-A4A805DC021E@endpoint.com>
<7EA65D44-7C3A-4FC2-8DE1-1F59BBB10B37@endpoint.com>
> On Oct 19, 2020, at 7:33 PM, David Christensen <david@endpoint.com> wrote:
>
> Maybe splitting LockRows into two nodes, one for locking and one for emitting unlocked nodes then interleaving Limit in between? (Or only doing something along these lines for this admittedly narrow use case. )
This does appear to be quite a bit harder than originally hoped for on the surface; creating a node to “pass-thru” unlocked tuples without locking them would require building out some additional infrastructure that does not appear to be present in all AMs; something to allow a test for locks without actually calling table_tuple_lock() formally. Perhaps adding a param to indicate “test” only—not sure if something like similar to heapam's “test_lockmode_for_conflict()” is something we’d need to had. (Or even a new lock mode which doesn’t create RowMarks but skips any conflicting modes.)
That said, I think it might be worth trying to go down the road of “forbid this behavior”, particularly if a workaround is available. Perhaps looking into why Álvaro’s plan was generating the multiple LockRows nodes would be more fruitful and less likely to cause backpatching pain.
David
--
David Christensen
Senior Software and Database Engineer
End Point Corporation
david@endpoint.com
785-727-1171
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: david@endpoint.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
In-Reply-To: <E75ECBBA-5902-4598-8F09-F36192E184EE@endpoint.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox