Re: pgsql: walreceiver uses a temporary replication slot by default
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
Sergei Kornilov <sk@zsrv.org>, Andres Freund <andres@anarazel.de>
Date: 2020-02-10T15:46:04Z
Lists: pgsql-hackers
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
Commits
-
Set wal_receiver_create_temp_slot PGC_POSTMASTER
- 092c6936de49 13.0 landed
-
walreceiver uses a temporary replication slot by default
- 329730827848 13.0 cited