Making WAL receiver startup rely on GUC context for primary_conninfoand primary_slot_name - Mailing list pgsql-hackers

From Michael Paquier
Subject Making WAL receiver startup rely on GUC context for primary_conninfoand primary_slot_name
Date
Msg-id 20181212053042.GK17695@paquier.xyz
Whole thread Raw
Responses Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name
List pgsql-hackers
Hi all,

Since 2dedf4d, recovery.conf is dead and all recovery parameters are now
GUCs.  While looking at a patch to switch primary_conninfo and
primary_slot_name to be reloadable, Sergei Kornilov had a very good
point that the WAL receiver uses a connection string and a physical slot
name based on what the startup process wants the WAL receiver to use:
https://www.postgresql.org/message-id/20181212043208.GI17695@paquier.xyz

It seems to me that doing so is now strange as the WAL receiver knows
about the GUC context, and actually it knows the parameters it should
use, so there is no point to pass down the values when requesting the
WAL receiver to start.

What do you think about the attached to simplify the logic?  Even if
primary_conninfo and primary_slot_name are not switched to SIGHUP this
cleanup looks like a good thing to me.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add timeline to partial WAL segments
Next
From: Andres Freund
Date:
Subject: Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name