Closed rheaton closed 2 years ago
Hi @rheaton and @jchampio ; we added the ability to restart Postgres when reacting to replication configuration changes in the PR that introduced this call to CHECKPOINT. We call CHECKPOINT before restart to reduce the time window when it's impossible to connect to Postgres. I suppose in spirit it's the same as in the fsm_checkpoint_and_stop_postgres
function, see src/bin/pg_autoctl/fsm_transition.c#L812-L822.
Now it seems to me that a good way to fix the user experience in the case you're reporting would be to check if Postgres is running first. When it's running, do as we do now. When it's not running, we don't need to CHECKPOINT, and we don't need to restart, we only need to start the service with the usual ensure_postgres_service_is_running
call.
Observed on pg10 and pg11 (may be present in others):
This issue is problematic if there is a large PGCONNECT_TIMEOUT, as the checkpoint attempts for that timeout, before restarting postgres. The server will take PGCONNECT_TIMEOUT to come up, which is surprising.
Steps to reproduce:
pg_autoctl config set
to update the replication password on the standbyWe spent some time looking around the code, and we noticed the checkpoint line in keeper.c was added in a seemingly (to us) unrelated commit, and we aren't entirely clear why we are doing it when we haven't made a successful connection yet.
Logs:
Thanks! Rachel & @jchampio