Hi,
The attached pgbench testcase can reproduce two issues:
1) (takes a bit)
TRAP: FailedAssertion("!(((xid) >= ((TransactionId) 3)))", File:/pruneheap.c",
Line: 601)
That's because HeapTupleHeaderGetUpdateXid() ignores aborted updaters
and returns InvalidTransactionId in that case, but
HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DELETE_IN_PROGRESS...
Looks like a 9.3+ issue, and shouldn't have a ll that high impact in
non-assert builds, page pruning will be delayed a bit.
2) we frequently error out in heap_lock_updated_tuple_rec() with
ERROR: unable to fetch updated version of tuple
That's because when we're following a ctid chain, it's perfectly
possible for the updated version of a tuple to already have been
vacuumed/pruned away if the the updating transaction has aborted.
Also looks like a 9.3+ issues to me, slightly higher impact, but in the
end you're just getting some errors under concurrency.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
BEGIN;
DROP TABLE IF EXISTS data, referenced;
CREATE TABLE referenced(
referenced_id serial primary key,
data int NOT NULL
);
CREATE TABLE data(
data_id serial primary key,
referenced_id int NOT NULL REFERENCES referenced,
data int NOT NULL
);
INSERT INTO referenced SELECT nextval('referenced_referenced_id_seq'), 1 FROM
generate_series(1, 20);
INSERT INTO data(referenced_id, data)
SELECT trunc(random()*20+1)::int, g.i
FROM generate_series(1, 100000) g(i);
COMMIT;
\setrandom ref 1 20
BEGIN;
SELECT * FROM referenced WHERE referenced_id = :ref FOR KEY SHARE;
SAVEPOINT f;
UPDATE referenced SET data = data WHERE referenced_id = :ref;
ROLLBACK TO SAVEPOINT f;
COMMIT;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
