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

From: David Christensen <david(at)endpoint(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
Date: 2020-10-19 23:59:21
Message-ID: 7B98FC76-00EE-4441-AF10-A4A805DC021E@endpoint.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On Oct 19, 2020, at 6:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Christensen <david(at)endpoint(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Christensen 2020-10-20 00:33:03 Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return
Previous Message Tom Lane 2020-10-19 23:07:10 Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return