Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Date
Msg-id 20190111004147.d6g2si7dtfi2sbtu@alap3.anarazel.de
Whole thread Raw
In response to Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Michael Paquier <michael@paquier.xyz>)
Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2019-01-11 09:34:28 +0900, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 02:20:27PM +0300, Sergei Kornilov wrote:
> > Thank you, patch looks good for me.
> 
> Thanks Sergei for the review.  I have been looking at the patch again
> this morning with a fresh set of eyes and the thing looks in a
> committable shape (the GUC values for NULL checks are a bit
> inconsistent in the last patch by the way, so I have fixed them
> locally).
> 
> I'll do an extra pass on it in the next couple of days and commit.
> Then let's move on with the reloadable portions.

I still think this whole direction of accessing the GUC in walreceiver
is a bad idea and shouldn't be pursued further.  There's definite
potential for startup process and WAL receiver having different states
of GUCs, the code doesn't get meaningfully simpler, the GUC value checks
in walreceiver make for horrible reporting up the chain.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Next
From: Michael Paquier
Date:
Subject: Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name