Thomas Munro wrote: > 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.
Interesting -- perhaps this helps explain the deadlock issue reported in http://www.postgresql.org/message-id/cakrjmhdn+ghajnwqfhsotgp+7yn27zr79m99rcajmnazt5n...@mail.gmail.com > 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... Does this help? http://www.postgresql.org/message-id/51fb4305.3070...@2ndquadrant.com The useful trick there is forcing a query to get its snapshot and then go to sleep before actually doing anything, by way of an advisory lock. -- Á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
