Skip to content

Commit 484a848

Browse files
committed
Fix pg_rewind regression failure after "fast promotion"
pg_rewind looks at the control file to determine the server's timeline. If the standby performs a "fast promotion", the timeline ID in the control file is not updated until the next checkpoint. The startup process requests a checkpoint immediately after promotion, so this is unlikely to be an issue in the real world, but the regression suite ran pg_rewind so quickly after promotion that the checkpoint had not yet completed. Reported by Stephen Frost
1 parent 9d396af commit 484a848

File tree

1 file changed

+8
-0
lines changed

1 file changed

+8
-0
lines changed

src/bin/pg_rewind/RewindTest.pm

+8
Original file line numberDiff line numberDiff line change
@@ -242,6 +242,14 @@ sub promote_standby
242242
system_or_bail("pg_ctl -w -D $test_standby_datadir promote >>$log_path 2>&1");
243243
poll_query_until("SELECT NOT pg_is_in_recovery()", $connstr_standby)
244244
or die "Timed out while waiting for promotion of standby";
245+
246+
# Force a checkpoint after the promotion. pg_rewind looks at the control
247+
# file todetermine what timeline the server is on, and that isn't updated
248+
# immediately at promotion, but only at the next checkpoint. When running
249+
# pg_rewind in remote mode, it's possible that we complete the test steps
250+
# after promotion so quickly that when pg_rewind runs, the standby has not
251+
# performed a checkpoint after promotion yet.
252+
standby_psql("checkpoint");
245253
}
246254

247255
sub run_pg_rewind

0 commit comments

Comments
 (0)