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

On December 11, 2018 9:30:42 PM PST, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>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.

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.

Andres

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.