8000 Log the correct ending timestamp in recovery_target_xid mode. · postgres/postgres@0a26952 · GitHub
[go: up one dir, main page]

Skip to content

Commit 0a26952

Browse files
committed
Log the correct ending timestamp in recovery_target_xid mode.
When ending recovery based on recovery_target_xid matching with recovery_target_inclusive = off, we printed an incorrect timestamp (always 2000-01-01) in the "recovery stopping before ... transaction" log message. This is a consequence of sloppy refactoring in c945af8: the code to fetch recordXtime out of the commit/abort record used to be executed unconditionally, but it was changed to get called only in the RECOVERY_TARGET_TIME case. We need only flip the order of operations to restore the intended behavior. Per report from Torsten Förtsch. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAKkG4_kUevPqbmyOfLajx7opAQk6Cvwkvx0HRcFjSPfRPTXanA@mail.gmail.com
1 parent 0c2f34a commit 0a26952

File tree

1 file changed

+7
-2
lines changed
  • src/backend/access/transam

1 file changed

+7
-2
lines changed

src/backend/access/transam/xlog.c

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5914,8 +5914,13 @@ recoveryStopsBefore(XLogReaderState *record)
59145914
stopsHere = (recordXid == recoveryTargetXid);
59155915
}
59165916

5917-
if (recoveryTarget == RECOVERY_TARGET_TIME &&
5918-
getRecordTimestamp(record, &recordXtime))
5917+
/*
5918+
* Note: we must fetch recordXtime regardless of recoveryTarget setting.
5919+
* We don't expect getRecordTimestamp ever to fail, since we already know
5920+
* this is a commit or abort record; but test its result anyway.
5921+
*/
5922+
if (getRecordTimestamp(record, &recordXtime) &&
5923+
recoveryTarget == RECOVERY_TARGET_TIME)
59195924
{
59205925
/*
59215926
* There can be many transactions that share the same commit time, so

0 commit comments

Comments
 (0)
0