From 2503e5392198b11782fae85d269c048ab2ccfbbd Mon Sep 17 00:00:00 2001
From: alterego655 <824662526@qq.com>
Date: Wed, 5 Nov 2025 15:03:46 +0800
Subject: [PATCH v2] Fix timing issue in recovery/004_timeline_switch test

The test searched the entire log for walreceiver termination messages,
but restart() kills walreceiver and logs that exact message.  TAP tests
reuse log files, so the check would find the expected shutdown from
restart() and fail intermittently based on flush timing.

Fix by rotating to a fresh log file before restart(), so only messages
from the timeline switch itself are checked.
---
 src/test/recovery/t/004_timeline_switch.pl | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/test/recovery/t/004_timeline_switch.pl b/src/test/recovery/t/004_timeline_switch.pl
index 13874ff866f..7a855d68a5d 100644
--- a/src/test/recovery/t/004_timeline_switch.pl
+++ b/src/test/recovery/t/004_timeline_switch.pl
@@ -54,6 +54,12 @@ $node_standby_2->append_conf(
 	'postgresql.conf', qq(
 primary_conninfo='$connstr_1'
 ));
+
+# Rotate to a fresh log file before restart.  The restart will kill
+# walreceiver (logging a FATAL to the old file), but the new server
+# will log to the new file.  This way we can check only the new file
+# for issues during the timeline switch.
+$node_standby_2->rotate_logfile();
 $node_standby_2->restart;
 
 # Insert some data in standby 1 and check its presence in standby 2
@@ -66,10 +72,8 @@ my $result =
   $node_standby_2->safe_psql('postgres', "SELECT count(*) FROM tab_int");
 is($result, qq(2000), 'check content of standby 2');
 
-# Check the logs, WAL receiver should not have been stopped while
-# transitioning to its new timeline.  There is no need to rely on an
-# offset in this check of the server logs: a new log file is used on
-# node restart when primary_conninfo is updated above.
+# Check the new log file.  WAL receiver should not have been stopped
+# while transitioning to its new timeline.
 ok( !$node_standby_2->log_contains(
 		"FATAL: .* terminating walreceiver process due to administrator command"
 	),
-- 
2.51.0