| 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 | Resend email |
| 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 |
| 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 |