| From: | "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: allow online change primary_conninfo |
| Date: | 2019-01-31 12:58:37 |
| Message-ID: | 20190131125837.6gtbdslj5atasuoz@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-12-14 16:55:42 +0900, Michael Paquier wrote:
> On Thu, Dec 13, 2018 at 01:51:48PM +0300, Sergei Kornilov wrote:
> > Depends on this discussion: https://www.postgresql.org/message-id/20181212053042.GK17695@paquier.xyz
> > If walreceiver will use GUC conninfo for startup - then yes, we can
> > remove such static variables. If walreceiver will still use conninfo
> > from WalRcv - we have race condition between RequestXLogStreaming from
> > startup, config reload, and walreceiver start. In this case I need
> > save conninfo from WalRcv and compare new GUC value with them.
>
> I would recommend waiting for the conclusion of other thread before
> moving on with this one. There are arguments for letting the startup
> process deciding which connection string the WAL receiver should use as
> well as letting the WAL receiver use directly the connection string from
> the GUC.
I suggest continuing the development of the patch without relying on
that refactoring.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-01-31 13:02:57 | Re: bug tracking system |
| Previous Message | Andres Freund | 2019-01-31 12:53:49 | Re: tab-completion debug print |