From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Hiroyuki Yamada <yamada(at)kokolink(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hot Standby and prepared transactions |
Date: | 2009-12-17 13:18:55 |
Message-ID: | 4B2A2FBF.6090302@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2009-12-17 13:20:22 | Re: Update on true serializable techniques in MVCC |
Previous Message | Kevin Grittner | 2009-12-17 13:07:28 | Re: determine snapshot after obtaining locks for first statement |