Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name

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