From 239a548e9d5da326401ec5a00ed9c0c837d21d3c Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Thu, 29 Mar 2018 23:55:08 +0900 Subject: [PATCH] "standby switchover": force checkpoint if pg_rewind requested. Addresses issue described in GitHub #378. PostgreSQL itself doesn't issue a checkpoint after promotion to ensure the newly promoted server is available as quickly as possible, so we'll only execute an explicit CHECKPOINT when it's actually required, i.e. when pg_rewind will be executed. This is required as pg_rewind uses the timeline reported in the pg_control file to compare with the server to be rewound, and the pg_control timeline is only updated after the first checkpoint, so there is an interval where pg_rewind will erroneously assume both servers are on the timeline and take no action. --- repmgr-action-standby.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/repmgr-action-standby.c b/repmgr-action-standby.c index 6f66996d..a575dca6 100644 --- a/repmgr-action-standby.c +++ b/repmgr-action-standby.c @@ -3474,6 +3474,19 @@ x */ /* promote standby (local node) */ _do_standby_promote_internal(local_conn, config_file_options.data_directory); + + /* + * if pg_rewind is requested, issue a checkpoint immediately after promoting + * the local node, as pg_rewind compares timelines on the basis of the value + * in pg_control, which is written at the first checkpoint, which might not + * occur immediately. + */ + if (runtime_options.force_rewind == true) + { + log_notice(_("issuing CHECKPOINT")); + checkpoint(local_conn); + } + /* * Execute `repmgr node rejoin` to create recovery.conf and start the * remote server. Additionally execute "pg_rewind", if required and