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: