Allow reload recovery.conf during recovery
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38656psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:31 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38656_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38656_1 && git checkout t38656_1Patchset v1 (message #1) is on t38656_1
Hello all
I want propose patch to make possible change primary_conninfo, primary_slot_name, restore_command and trigger_file in recovery.conf without restart postgresql.
Startup process will reread recovery.conf on SIGHUP.
My primary usecase is postgresql cluster with streaming replication. When we lost current master and want promote new master we need restart all replicas with new primary_conninfo.
Another useful cases from my work:
- switch wal streaming to another NIC
- change replication username (or password when .pgpass was not used)
When restarting, shared buffers are lost; some time are spent in recovery from last restart point. But in some cases all we need is to change connection string.
Changing restore_command may be useful for users too.
I did not find previous discussions.
I split readRecoveryCommandFile to two functions:
- readRecoveryCommandFile with reading and validating recovery.conf and avoid side effects
- ProcessRecoveryCommandFile with other logic
Changing primary_conninfo or primary_slot_name will restart walreceiver (i do not touch walreceiver source, i request standard restart)
trigger_file was not my primary target, but i not find any reason to decline this change on reload (also did not find any tests with trigger_file, i add one). I am not sure about all other settings like recovery_min_apply_delay, archive_cleanup_command and etc, so i forbid these changes.
Patch to current master. Changes to the documentation and a few additional tests are included.
PS: of course, i do not mean postgresql 11
regards, Sergei
On Fri, May 04, 2018 at 05:19:26PM +0300, Sergei Kornilov wrote:
I did not find previous discussions.
There have been a lot of discussions across the years about switching
recovery parameters to use the GUC infrastructure, please see those
two ones:
/messages/by-id/CABUevEy5aWuwySXEC6i3JA6cvy8agGZHQbOn0RVZ4h4oxM0Dkw@mail.gmail.com
/messages/by-id/CAJKUy5id1eyweK0W4+yyCM6+-qYs9erLidUmb=1a-QYBgTW4Qw@mail.gmail.com
And more recently this one which reached a kind of agreement:
/messages/by-id/CANP8+jLO5fmfudbB1b1iw3pTdOK1HBM=xMTaRfOa5zpDVcqzew@mail.gmail.com
Parameters in recovery.conf now have a level equivalent to
GUC_POSTMASTER as those are just read when the startup process finds a
recovery.conf file and are never changed. Before making some of them as
reloadable, let's switch them to be GUCs first and not re-invent the
SIGHUP handling of parameters as your patch does. And after let's
discuss about switching some of them to GUC_SIGHUP.
--
Michael