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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to