Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby.

On Wed, 2008-10-22 at 13:25 -0400, Tom Lane wrote:
> alvherre@postgresql.org (Alvaro Herrera) writes:
> > Rework subtransaction commit protocol for hot standby.
> 
> I think this patch broke something.  In CVS HEAD, replay of a
> transaction commit record with a subtransaction dies with an assert
> failure:
> 
> #0  0xc0141220 in ?? () from /usr/lib/libc.1
> #1  0xc00aa7ec in ?? () from /usr/lib/libc.1
> #2  0xc008c2b8 in ?? () from /usr/lib/libc.1
> #3  0xc0086d9c in ?? () from /usr/lib/libc.1
> #4  0x41288c in ExceptionalCondition (
>     conditionName=0x6deb8 "!(((*byteptr >> bshift) & ((1 << 2) - 1)) == 0 || ((*byteptr >> bshift) & ((1 << 2) - 1))
==0x03 || ((*byteptr >> bshift) & ((1 << 2) - 1)) == status)", errorType=0x6dde4 "FailedAssertion", 
 
>     fileName=0x6ddf4 "clog.c", lineNumber=330) at assert.c:57
> #5  0x171680 in TransactionIdSetStatusBit (xid=2063810256, status=2063810248, 
>     lsn={xlogid = 0, xrecoff = 0}, slotno=0) at clog.c:330
> #6  0x1714e8 in TransactionIdSetPageStatus (xid=84, nsubxids=1, 
>     subxids=0x4008dd78, status=2063840993, lsn={xlogid = 0, xrecoff = 0}, 
>     pageno=0) at clog.c:290
> #7  0x1712dc in TransactionIdSetTreeStatus (xid=19394, nsubxids=1, 
>     subxids=0x4008dd78, status=1, lsn={xlogid = 0, xrecoff = 0}) at clog.c:204
> #8  0x1722f8 in TransactionIdCommitTree (xid=2063670312, nxids=2063839972, 
>     xids=0x7b011cf0) at transam.c:266
> #9  0x1785b8 in xact_redo_commit (xlrec=0x4008dd48, xid=19394) at xact.c:4222
> #10 0x1788ec in xact_redo (lsn={xlogid = 0, xrecoff = 211142048}, 
>     record=0x4008dd28) at xact.c:4327
> #11 0x182a28 in StartupXLOG () at xlog.c:5146
> 
> I can't reproduce this 100% reliably, but the case where I saw it came
> from mistakenly inserting
>     Assert(!IsA(node, AppendRelInfo));
> into flatten_join_alias_vars_mutator and then running the serial
> regression tests.  This case *can* happen, but it doesn't occur
> until late in the regression tests.  The recovery ensuing from the
> assert failure crashes maybe one time in two --- likely has something
> to do with when the last checkpoint happened.

OK, looking now.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support