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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
