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

Reply via email to