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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, simon(at)2ndquadrant(dot)com, ams(at)2ndquadrant(dot)com, sk(at)zsrv(dot)org, masao(dot)fujii(at)gmail(dot)com
Subject: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name
Date: 2018-12-12 05:30:42
Message-ID: 20181212053042.GK17695@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: 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 Content-Type Size
walreceiver-gucs-v1.patch text/x-diff 4.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-12-12 05:34:58 Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name
Previous Message Michael Paquier 2018-12-12 05:14:13 Re: Add timeline to partial WAL segments