From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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-03-04 03:19:18 |
Message-ID: | 20190304031918.GH1999@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 02, 2019 at 01:49:51PM +0300, Sergei Kornilov wrote:
> This might be not the right way, but I can't think of a better way
> to not switch to a different method than split of lastSourceFailed
> processing and starting new source. Something like refactoring in
> first attached patch. I move RequestXLogStreaming logic from
> lastSourceFailed processing and add new pendingRestartSource
> indicator.
OK. This needs a rather close lookup, and I am not actually sure that
you even need pendingRestartSource. Please let me a couple of days
before coming back to you on 0001.
> Second patch is mostly the same as previous version but uses new
> pendingRestartSource mechanism instead of lastSourceFailed.
This, on the other hand, looks like the implementation we are looking
for based on the discussions which happened until now to have the
startup process handle the shutdown and restart of the WAL receiver.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2019-03-04 03:24:48 | Re: [HACKERS] WAL logging problem in 9.4.3? |
Previous Message | Etsuro Fujita | 2019-03-04 03:10:53 | Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns |