On Wed, 2008-10-22 at 16:41 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > 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. > > Hmm, but then why did we not see the same thing before?
The failure definitely came from trying to set SUBCOMMITTED on a transaction already committed. I drew the wrong initial conclusion from the Assert, which applied only to normal running, not recovery. As you suggested, something to do with sequencing of checkpoints? Previously the error showed itself consistently on the second run on make installcheck. The attached patch succeeds consistently at the same place. And keeps succeeding on third, fourth, fifth times. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
