mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-27 08:56:29 +00:00
Check that there is no exclusive backup taking place while we perform
a switchover. We've found that this can cause some issues with postgres control metadata (could be a postgres bug) so best thing is *not* no switchover if there's a backup taking place. It's also a bad idea from an architectual point of view, as a switchover is supposed to be planed, so why perform it when we are taking backups. GitHub #476.
This commit is contained in:
committed by
Ian Barwick
parent
ef35d071bf
commit
8f13a66aaa
@@ -2911,6 +2911,24 @@ do_standby_switchover(void)
|
||||
exit(ERR_DB_QUERY);
|
||||
}
|
||||
|
||||
/*
|
||||
* Check that there's no exclusive backups running on the primary.
|
||||
* We don't want to end up damaging the backup and also leaving the server in an
|
||||
* state where there's control data saying it's in backup mode but there's no
|
||||
* backup_label in PGDATA.
|
||||
* If the DBA wants to do the switchover anyway, he should first stop the
|
||||
* backup that's running.
|
||||
*/
|
||||
if (!server_not_in_exclusive_backup_mode(remote_conn))
|
||||
{
|
||||
log_error(_("can't perform a switchover while primary server is in exclusive backup mode"));
|
||||
log_hint(_("stop backup before attempting the switchover"));
|
||||
|
||||
PQfinish(remote_conn);
|
||||
|
||||
exit(ERR_SWITCHOVER_FAIL);
|
||||
}
|
||||
|
||||
/*
|
||||
* Check this standby is attached to the demotion candidate
|
||||
* TODO:
|
||||
|
||||
Reference in New Issue
Block a user