Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return - Mailing list pgsql-bugs

From David Christensen
Subject Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
Date
Msg-id 7B98FC76-00EE-4441-AF10-A4A805DC021E@endpoint.com
Whole thread Raw
In response to Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return  (David Christensen <david@endpoint.com>)
List pgsql-bugs
> On Oct 19, 2020, at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Christensen <david@endpoint.com> writes:
>> Proposed fix:
>> Reorder Limit/LockRows nodes to prevent locking extra tuples in FETCH FIRST WITH TIES
>
> Isn't that going to break more cases than it fixes?

In the case of Limit, isn’t LockRows supposed to only lock the number of actual rows returned?

What are the scenarios that this might break and do you have any ideas for alternate fixes?

David


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
Next
From: David Christensen
Date:
Subject: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return