On 28 August 2014 00:25, Alvaro Herrera <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
