> 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
inbetween? (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”
unlockedtuples without locking them would require building out some additional infrastructure that does not appear to
bepresent in all AMs; something to allow a test for locks without actually calling table_tuple_lock() formally. Perhaps
addinga param to indicate “test” only—not sure if something like similar to heapam's “test_lockmode_for_conflict()” is
somethingwe’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
isavailable. Perhaps looking into why Álvaro’s plan was generating the multiple LockRows nodes would be more fruitful
andless likely to cause backpatching pain.
David
--
David Christensen
Senior Software and Database Engineer
End Point Corporation
david@endpoint.com
785-727-1171