Can I just reload the slave to change primary_conninfo?
Hi All,
If I need to change the master address from which the slave
replicates, must I restart the postgresql? Or just reload is ok?
On Mon, Sep 10, 2018 at 04:32:39PM +0800, Jinhua Luo wrote:
If I need to change the master address from which the slave
replicates, must I restart the postgresql? Or just reload is ok?
This parameter is defined in postgresql.conf, you need to restart the
instance.
--
Michael
Hi
This parameter is defined in postgresql.conf
Huh, i believe it be in future.
Currently it is recovery.conf parameter, and yes - it can be set (or changed) only at database start.
regards, Sergei
On Mon, Sep 10, 2018 at 12:08:07PM +0300, Sergei Kornilov wrote:
This parameter is defined in postgresql.conf
Huh, i believe it be in future.
Currently it is recovery.conf parameter, and yes - it can be set (or
changed) only at database start.
Thanks Sergei for the correction. Indeed you need to read that as
recovery.conf, not postgresql.conf.
--
Michael
On Mon, Sep 10, 2018 at 1:36 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Sep 10, 2018 at 12:08:07PM +0300, Sergei Kornilov wrote:
This parameter is defined in postgresql.conf
Huh, i believe it be in future.
Currently it is recovery.conf parameter, and yes - it can be set (or
changed) only at database start.Thanks Sergei for the correction. Indeed you need to read that as
recovery.conf, not postgresql.conf.
Is there any reason this cannot be changed via a signal? Is it a general
lack of infrastructure or is it there significant problem we want to ensure
never happens?
--
Michael
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
Hello
Is there any reason this cannot be changed via a signal? Is it a general lack of infrastructure or is it there significant problem we want to ensure never happens?
Just make possible reload recovery.conf is not what the pgsql-hackers community want. My patch with exactly this feature was rejected with this reason.
There were already some discussions about move recovery.conf into GUC infrastructure first. I continue work on one most recent patch here: https://commitfest.postgresql.org/19/1711/ If this patch will be committed - i plan sent new patch to allow change primary_conninfo with SIGHUP.
regards, Sergei
On Mon, Sep 10, 2018 at 06:12:52PM +0300, Sergei Kornilov wrote:
There were already some discussions about move recovery.conf into GUC
infrastructure first. I continue work on one most recent patch here:
https://commitfest.postgresql.org/19/1711/ If this patch will be
committed - i plan sent new patch to allow change primary_conninfo
with SIGHUP.
Nice to hear that! Please make sure that in the first flavor of the
patch all the recovery parameters are switched to GUC_POSTMASTER so as
they map with the existing behavior. We should move a subset of those
parameters to SIGHUP after a careful lookup, and as a secondary step.
--
Michael