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

diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index a5f7d08bf72afd6d8bfdc3398f703eaa989b2913..6ea2f871aab6bfd38cd8e9e300222a32829cd6fb 100644 (file)
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -242,6 +242,14 @@ sub promote_standby
        system_or_bail("pg_ctl -w -D $test_standby_datadir promote >>$log_path 2>&1");
        poll_query_until("SELECT NOT pg_is_in_recovery()", $connstr_standby)
                or die "Timed out while waiting for promotion of standby";
+
+       # Force a checkpoint after the promotion. pg_rewind looks at the control
+       # file todetermine what timeline the server is on, and that isn't updated
+       # immediately at promotion, but only at the next checkpoint. When running
+       # pg_rewind in remote mode, it's possible that we complete the test steps
+       # after promotion so quickly that when pg_rewind runs, the standby has not
+       # performed a checkpoint after promotion yet.
+       standby_psql("checkpoint");
 }
 
 sub run_pg_rewind