Re: allow online change primary_conninfo

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Sergei Kornilov <sk(at)zsrv(dot)org>, David Steele <david(at)pgmasters(dot)net>, 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-04-04 02:13:30
Message-ID: 20190404021330.od4bmfyj3wdv5yhg@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 2019-04-04 11:06:05 +0900, Michael Paquier wrote:
> On Thu, Apr 04, 2019 at 12:27:55AM +0300, Sergei Kornilov wrote:
> > Not agree. Latest patch version perform walreceiver restart without
> > switch to a different method as discussed. Here is no race condition
> > between startup process and walreceiver because conninfo passed via
> > WalRcvData struct as currently. I miss something important?
> > Michael Paquier had no possibility to review latest implementation,
> > but did not say this is totally wrong, just asked wait a rather
> > close lookup.
>
> I agree with Sergei's statement here. He has sent a patch for review,
> which I have looked up a bit, but not enough to provide a full review
> unfortunately, and this even if I was listed as a reviewer of it. So
> if somebody is to blame here, that's me.

> > Of cource we can close this cf entry. I would be happy if someone
> > else post proper implementation. And I can rework my implementation
> > again, but I don’t know how the correct implementation should look
> > or why latest implementation is wrong.
>
> Moving this patch to next CF is fine.

Cool, sorry for the misunderstanding then.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-04-04 02:28:08 Re: New vacuum option to do only freezing
Previous Message David Rowley 2019-04-04 02:13:10 Re: Inadequate executor locking of indexes