mirror of
				https://github.com/postgres/postgres.git
				synced 2025-11-03 09:13:20 +03:00 
			
		
		
		
	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
c945af80c: 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
			
			
This commit is contained in:
		@@ -2548,8 +2548,13 @@ recoveryStopsBefore(XLogReaderState *record)
 | 
				
			|||||||
		stopsHere = (recordXid == recoveryTargetXid);
 | 
							stopsHere = (recordXid == recoveryTargetXid);
 | 
				
			||||||
	}
 | 
						}
 | 
				
			||||||
 | 
					
 | 
				
			||||||
	if (recoveryTarget == RECOVERY_TARGET_TIME &&
 | 
						/*
 | 
				
			||||||
		getRecordTimestamp(record, &recordXtime))
 | 
						 * Note: we must fetch recordXtime regardless of recoveryTarget setting.
 | 
				
			||||||
 | 
						 * We don't expect getRecordTimestamp ever to fail, since we already know
 | 
				
			||||||
 | 
						 * this is a commit or abort record; but test its result anyway.
 | 
				
			||||||
 | 
						 */
 | 
				
			||||||
 | 
						if (getRecordTimestamp(record, &recordXtime) &&
 | 
				
			||||||
 | 
							recoveryTarget == RECOVERY_TARGET_TIME)
 | 
				
			||||||
	{
 | 
						{
 | 
				
			||||||
		/*
 | 
							/*
 | 
				
			||||||
		 * There can be many transactions that share the same commit time, so
 | 
							 * There can be many transactions that share the same commit time, so
 | 
				
			||||||
 
 | 
				
			|||||||
		Reference in New Issue
	
	Block a user