On Wed, 2008-10-22 at 20:52 +0100, Simon Riggs wrote: > Took a while, but yes, I can reproduce this now. Analysing...
OK, I think I see what it's doing and why it fails the assert. It's nothing to do with confusing commit/abort. The new way of doing things on commit is to subcommit then commit. This sequence is repeated during WAL replay. If we crash, it will try to repeat the sequence, so in some cases it will try to set status to subcommitted on a transaction already marked as committed. So it fails the Assertion, but does the right thing. A few ways to fix this, but patch to make that case a no-op is attached. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Index: src/backend/access/transam/clog.c =================================================================== RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/clog.c,v retrieving revision 1.48 diff -c -r1.48 clog.c *** src/backend/access/transam/clog.c 20 Oct 2008 19:18:18 -0000 1.48 --- src/backend/access/transam/clog.c 22 Oct 2008 20:24:29 -0000 *************** *** 324,329 **** --- 324,333 ---- byteptr = ClogCtl->shared->page_buffer[slotno] + byteno; + if (((*byteptr >> bshift) & CLOG_XACT_BITMASK) == TRANSACTION_STATUS_COMMITTED && + status == TRANSACTION_STATUS_SUB_COMMITTED) + return; + /* Current state should be 0, subcommitted or target state */ Assert(((*byteptr >> bshift) & CLOG_XACT_BITMASK) == 0 || ((*byteptr >> bshift) & CLOG_XACT_BITMASK) == TRANSACTION_STATUS_SUB_COMMITTED ||
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
