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

On Thu, Jan 10, 2019 at 04:52:53PM -0800, Andres Freund wrote:
> It's a minor simplification for code that's existed for quite a
> while. Not worth it.

Meh, I disagree for the ready_to_display part as it has been around
for a long time:
commit: 9ed551e0a4fdb046d8e5ea779adfd3e184d5dc0d
author: Alvaro Herrera <alvherre@alvh.no-ip.org>
date: Wed, 29 Jun 2016 16:57:17 -0400
Add conninfo to pg_stat_wal_receiver

I was honestly unhappy from the start with it because there was no
actual way to have the WAL receiver *not* save the original connection
string.  In my opinion, getting rid of it is worth it because this
really simplifies the way the WAL receiver data visibility is handled
at SQL level and we don't finish by using again and again the same
field for different purposes, consolidating the code.

For the reloading part, we also make the WAL receiver rely on the GUC
context and stop it if there is a change in primary_conninfo and
primary_slot_name.  It would be inconsistent to rely on the GUC
context for one thing, and the startup process for the other one.
Adding a safeguard to fail WAL receiver startup is actually more of
sanity check that anything else (that could be an assertion but for
forks a failure is of better benefit).

At this stage, I would like to hear more opinions before doing or not
doing something.  Alvaro, you got involved in the introduction of
ready_to_siplay.  Peter, you have committed the merge of the recovery
params.  Perhaps you have an opinion to share?
--
Michael