On 28 August 2014 00:25, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Thomas Munro wrote: >> I haven't yet figured out how to get get into a situation where >> heap_lock_updated_tuple_rec waits. > > Well, as I think I said in the first post I mentioned this, maybe there > is no such situation. In any case, like the EvalPlanQualFetch issue, we > can fix it later if we find it.
I finally came up with a NOWAIT spec that reaches heap_lock_updated_rec and then blocks. I can't explain why exactly... but please see attached. The fix seems fairly straightforward. Do you think I should submit an independent patch to fix this case (well there are really two cases, since there is a separate multixact path) for the existing NOWAIT support and then tackle the SKIP LOCKED equivalent separately? Best regards, Thomas Munro
# Test NOWAIT with an updated tuple chain (heap_lock_updated_tuple case) setup { CREATE TABLE foo ( id int PRIMARY KEY, data text NOT NULL ); INSERT INTO foo VALUES (1, 'x'); } teardown { DROP TABLE foo; } session "s1" setup { BEGIN; } step "s1a" { SELECT * FROM foo WHERE pg_advisory_lock(0) IS NOT NULL FOR KEY SHARE NOWAIT; } step "s1b" { COMMIT; } session "s2" setup { BEGIN; } step "s2a" { SELECT pg_advisory_lock(0); } step "s2b" { UPDATE foo SET id = id; UPDATE foo SET id = id + 10; } step "s2c" { SELECT pg_advisory_unlock(0); } step "s2d" { COMMIT; } permutation "s2a" "s1a" "s2b" "s2c" "s1b" "s2d"
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers