Обсуждение: 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

Hello

> Is there any reason this cannot be changed via a signal?  Is it a general lack of infrastructure or is it there
significantproblem 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
featurewas rejected with this reason.
 
There were already some discussions about move recovery.conf into GUC infrastructure first. I continue work on one most
recentpatch here: https://commitfest.postgresql.org/19/1711/ If this patch will be committed - i plan sent new patch to
allowchange 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