Re: [HACKERS] PANIC in pg_commit_ts slru after crashes - Mailing list pgsql-hackers

Since all those offsets fall on a page boundary, my guess is that we're somehow failing to handle a new page correctly.

Looking at the patch itself, my feeling is that the following code in src/backend/access/transam/twophase.c might be causing the problem. 

1841 

1842     /* update nextXid if needed */

1843     if (TransactionIdFollowsOrEquals(maxsubxid, ShmemVariableCache->nextXid))

1844     {

1845         LWLockAcquire(XidGenLock, LW_EXCLUSIVE);

1846         ShmemVariableCache->nextXid = maxsubxid;

1847         TransactionIdAdvance(ShmemVariableCache->nextXid);

1848         LWLockRelease(XidGenLock);

1849     }

The function PrescanPreparedTransactions() gets called at the start of the redo recovery and this specific block will get exercised irrespective of whether there are any prepared transactions or not. What I find particularly wrong here is that we are initialising maxsubxid to current value of ShmemVariableCache->nextXid when the function enters, but this block would then again increment ShmemVariableCache->nextXid, when there are no prepared transactions in the system.

I wonder if we should do as in attached patch.