From: Heikki Linnakangas Date: Fri, 1 May 2015 04:57:18 +0000 (-0700) Subject: Fix pg_rewind regression failure after "fast promotion" X-Git-Tag: REL9_5_ALPHA1~360 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=484a848a73fc5a76c16bc73626b290154b6a57b4;p=postgresql 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 a5f7d08bf7..6ea2f871aa 100644 --- 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