Hi, On 2020-02-10 16:46:04 +0100, Peter Eisentraut wrote: > 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.qphwrraj66rht...@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.
Yes, that was my concern there. I do agree there's much less of an issue here. I still architecturally don't find it attractive that the active configuration between walreceiver and startup process can diverge though. Imagine if we e.g. added the ability to receive WAL over multiple connections from one host, or from multiple hosts (e.g. to be able to get the bulk of the WAL from a cascading node, but also to provide syncrep acknowledgements directly to the primary), or to allow for logical replication without needing all WAL locally on a standby doing decoding. It seems not great if there's potentially diverging configuration (hot standby feedback, temporary slots, ... ) between those walreceivers, just depending on when they started. Here the model e.g. paralell workers use, which explicitly ensure that the GUC state is the same in workers and the leader, is considerably better, imo. So I think adding more of these parameters affecting walreceivers without coordination is not going quite in the right direction. Greetings, Andres Freund
