On 2020-01-22 06:55, Michael Paquier wrote:
> In the thread about switching primary_conninfo to be reloadable, we
> have argued at great lengths that we should never have the WAL
> receiver fetch by itself the GUC parameters used for the connection
> with its primary. Here is the main area of the discussion:
> https://www.postgresql.org/message-id/20190217192720.qphwrraj66rht5lj@alap3.anarazel.de
The way I understood that discussion was that the issue is having both
the startup process and the WAL receiver having possibly inconsistent
knowledge about the current configuration. That doesn't apply in this
case, because the setting is only used by the WAL receiver. Maybe I
misunderstood.
> The previous thread was long enough so it can easily be missed.
> However, it seems to me that we may need to revisit a couple of things
> for this commit? In short, the following things:
> - wal_receiver_create_temp_slot should be made PGC_POSTMASTER,
> similarly to primary_slot_name and primary_conninfo.
> - WalReceiverMain() should not load the parameter from the GUC context
> by itself.
> - RequestXLogStreaming(), called by the startup process, should be in
> charge of defining if a temp slot should be used or not.
That would be a reasonable fix if we think the above is really an issue.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services