Alvaro Herrera wrote:
> Andres Freund wrote:
> > * heap_lock_tuple with mode == LockTupleKeyShare && nowait looks like it would
> > wait anyway in heap_lock_updated_tuple_rec
>
> Oops.
I took a stab at fixing this. However, it is not easy. First you need
a way to reproduce the problem, which involves setting breakpoints in
GDB. (Since a REPEATABLE READ transaction will fail to follow an update
chain due to "tuple concurrently updated", you need to use a READ
COMMITTED transaction; but obviously the timing to insert the bunch of
updates in the middle is really short. Hence I inserted a breakpoint at
the end of GetSnapshotData, had a SELECT FOR KEY SHARE NOWAIT get stuck
in it, and then launched a couple of updates in another session). I was
able to reproduce the undesirable wait.
I quickly patched heap_lock_updated_tuple to pass down the nowait flag,
but this is actually not reached, because the update chain is first
followed by EvalPlanQual in ExecLockRows, and not by
heap_lock_updated_tuple directly. And EPQ does not have the nowait
behavior. So it still blocks.
Maybe what we need to do is prevent ExecLockRows from following the
update chain altogether -- after all, if heap_lock_tuple is going to do
it by itself maybe it's wholly redundant.
Not really sure what's the best way to approach this. At this stage I'm
inclined to ignore the problem, unless some EPQ expert shows up and
tells me that (1) it's okay to patch EPQ in that way, or (2) we should
hack ExecLockRows (and remove EPQ?).
I pushed (to github) patches for a couple of other issues you raised.
Some others still need a bit more of my attention.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services