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

On Tue, Dec 11, 2018 at 09:34:58PM -0800, Andres Freund wrote:
> I am not convinced this is a good idea. This allows the state of
> walrcv and startup to diverge, they could e.g. have different
> configuration, due to differently time config reloads.  And they need
> to communicate via shmem anyway, so there's not a lot of complexity
> avoided.  And I think it's good to be able to show the active
> connection via functions, rather than the one currently in pg.conf,
> which might be different.

Well, the conninfo and slot name accessible to the user are the values
available only once the information of the WAL receiver in shared memory
is ready to be displayed.  Relying more on the GUC context has the
advantage to never have in shared memory the original string and only
store the clobbered one, which actually simplifies what's stored in
shared memory because you can entirely remove ready_to_display (I forgot
to remove that in the patch actually).  If those parameters become
reloadable, you actually rely only on what the param context has, and
not on what the shared memory context may have or not.

Removing entirely ready_to_display is quite appealing actually..
--
Michael