Re: Hot Standby and prepared transactions - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Re: Hot Standby and prepared transactions |
Date | |
Msg-id | 4B2A2FBF.6090302@enterprisedb.com Whole thread Raw |
In response to | Re: Hot Standby and prepared transactions (Simon Riggs <simon@2ndQuadrant.com>) |
Responses |
Re: Hot Standby and prepared transactions
|
List | pgsql-hackers |
Simon Riggs wrote: > On Thu, 2009-12-17 at 13:24 +0200, Heikki Linnakangas wrote: > >> Hmm, looking at the code, I think Simon threw that baby with the >> bathwater when he removed support for starting standby from a shutdown >> checkpoint. > > Hmm, I think that code was just for starting points only. It would not > have been executed in normal running of the standby, so it appears the > bug was older than that. Absence of baby now appears inconclusive. This is the piece of code we're talking about, in xlog_redo(): --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -7340,41 +7340,6 @@ xlog_redo(XLogRecPtr lsn, XLogRecord *record) ShmemVariableCache->oldestXid = checkPoint.oldestXid; ShmemVariableCache->oldestXidDB = checkPoint.oldestXidDB; - /* - * We know nothing was running on the master at this point, though - * we can only use it as a starting point iff wal_standby_info was - * enabled, otherwise we may not get further information about changes - * from the master. - */ - if (standbyState >= STANDBY_UNINITIALIZED && checkPoint.XLogStandbyInfoMode) - { - RunningTransactionsData running; - TransactionId oldestRunningXid; - TransactionId *xids; - int nxids; - - oldestRunningXid = PrescanPreparedTransactions(&xids, &nxids); - - /* - * Construct a RunningTransactions snapshot representing a shut - * down server, with only prepared transactions still alive. - * - * StandbyRecoverPreparedTransactions will call SubTransSetParent - * for any subtransactions, so we consider this a non-overflowed - * snapshot. - */ - running.xcnt = nxids; - running.subxid_overflow = false; - running.nextXid = checkPoint.nextXid; - running.oldestRunningXid = oldestRunningXid; - running.xids = xids; - - ProcArrayInitRecoveryInfo(oldestRunningXid); - ProcArrayApplyRecoveryInfo(&running); - - StandbyRecoverPreparedTransactions(); - } - /* Check to see if any changes to max_connections give problems */ if (standbyState != STANDBY_DISABLED) CheckRequiredParameterValues(checkPoint); That removed piece of code was executed in the standby whenever we saw a shutdown checkpoint. It calls ProcArrayApplyRecoveryInfo(), which calls ExpireOldKnownAssignedTransactionIds() and StandbyReleaseOldLocks() to clean up known-assigned-xid entries and locks of the implicitly-aborted transactions. I see now that in the presence of prepared transactions, we would fail to clean up failed transations with XID > the oldest prepared transaction, but other than that it looks fine to me. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
pgsql-hackers by date: