Fix recoveryLastXTime logic so that it actually does what one would expect.

Per gripe from Kevin Grittner.  Backpatch to 8.3, where the bug was introduced.
This commit is contained in:
Tom Lane 2008-10-30 04:06:25 +00:00
parent 4b2315f493
commit b56cdf3b85

View File

@ -7,7 +7,7 @@
* Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.292.2.4 2008/05/13 20:54:02 mha Exp $
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.292.2.5 2008/10/30 04:06:25 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -4661,6 +4661,9 @@ exitArchiveRecovery(TimeLineID endTLI, uint32 endLogId, uint32 endLogSeg)
*
* Returns TRUE if we are stopping, FALSE otherwise. On TRUE return,
* *includeThis is set TRUE if we should apply this record before stopping.
*
* We also track the timestamp of the latest applied COMMIT/ABORT record
* in recoveryLastXTime, for logging purposes.
* Also, some information is saved in recoveryStopXid et al for use in
* annotating the new timeline's history file.
*/
@ -4692,12 +4695,12 @@ recoveryStopsHere(XLogRecord *record, bool *includeThis)
else
return false;
/* Remember the most recent COMMIT/ABORT time for logging purposes */
recoveryLastXTime = recordXtime;
/* Do we have a PITR target at all? */
if (!recoveryTarget)
{
recoveryLastXTime = recordXtime;
return false;
}
if (recoveryTargetExact)
{
@ -4761,7 +4764,12 @@ recoveryStopsHere(XLogRecord *record, bool *includeThis)
recoveryStopXid,
timestamptz_to_str(recoveryStopTime))));
}
if (recoveryStopAfter)
recoveryLastXTime = recordXtime;
}
else
recoveryLastXTime = recordXtime;
return stopsHere;
}