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

From Michael Paquier
Subject Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Date
Msg-id 20190111005049.GA14237@paquier.xyz
Whole thread Raw
In response to Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Andres Freund <andres@anarazel.de>)
Responses Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Jan 10, 2019 at 04:41:47PM -0800, Andres Freund wrote:
> 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.

Did you notice the set of messages from upthread?  The code *gets*
simpler by removing ready_to_display and the need to manipulate the
non-clobbered connection string sent directly from the startup
process.  In my opinion that's a clear gain.  We gain also the
possibility to track down that a WAL receiver is started but not
connected yet for monitoring tools.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Next
From: Peter Geoghegan
Date:
Subject: Re: Using Btree to Provide Sorting on Suffix Keys with LIMIT