On 24 August 2014 22:04, Thomas Munro <mu...@ip9.org> wrote: > On 22 August 2014 23:02, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: >> Did you consider heap_lock_updated_tuple? A rationale for saying it >> doesn't need to pay attention to the wait policy is: if you're trying to >> lock-skip-locked an updated tuple, then you either skip it because its >> updater is running, or you return it because it's no longer running; and >> if you return it, it is not possible for the updater to be locking the >> updated version. However, what if there's a third transaction that >> locked the updated version? It might be difficult to hit this case or >> construct an isolationtester spec file though, since there's a narrow >> window you need to race to. > > Hmm. I will look into this, thanks.
While trying to produce the heap_lock_updated_tuple_rec case you describe (so far unsuccessfully), I discovered I could make SELECT ... FOR UPDATE NOWAIT block indefinitely on unpatched 9.3 in a different code path after heap_lock_tuple returns: in another session, UPDATE, COMMIT, then UPDATE, all after the first session has taken its snapshot but before it tries to lock a given row. The code in EvalPlanQualFetch (reached from the HeapTupleUpdated case in ExecLockRow) finishes up waiting for the uncommitted transaction. I think I see how to teach EvalPlanQualFetch how to handle wait policies: for NOWAIT it should ereport (fixing a pre-existing bug (?)), and I guess it should handle SKIP LOCKED by returning NULL, similarly to the way it handles deleted rows, and of course in all cases passing the wait policy forward to heap_lock_tuple, which it eventually calls. Still looking at heap_lock_updated_tuple. The difficulty of course will be testing all these racy cases reproducibly... Best regards, Thomas Munro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
