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

> On Oct 20, 2020, at 9:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>> On 2020-Oct-19, David Christensen 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.)
>
>> I was having a similar idea, but the main reason I don't think it's a
>> good fix is that we can't backpatch such a change to pg13.
>
> Um, why not? I don't have a position yet on whether this is a good way
> to fix it; but if we did do it, AFAICS the only thing we'd have to be
> careful of in v13 is not renumbering existing NodeTag values.
>
> If your concern is just that EXPLAIN plans will look different, the same
> could be said of David's other proposal.

If we can determine the scope to which these different nodes might be used and make it so it still uses the existing node structure for most existing cases (i.e., maybe an additional parameter to create_lockrows_plan or similar) then that might work; AFAIK, this is the first time we’ve had to consider this sort of thing (though I do wonder if there might be something in window functions which might bump into this sort of issue).

I’m working on an isolation test to formalize this failure, which I can do as a separate patch if we want to have this prior to implementing a fix.

--
David Christensen
Senior Software and Database Engineer
End Point Corporation
david(at)endpoint(dot)com
785-727-1171