On Mon, Feb 10, 2020 at 01:46:04PM -0800, Andres Freund wrote: > 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. parallel workers use, which explicitly ensure that the GUC state is > the same in workers and the leader, is considerably better, imo.
Yes, I still think that we should fix that inconsistency, mark the new GUC wal_receiver_create_temp_slot as PGC_POSTMASTER, and add a note at the top of RequestXLogStreaming() and walreceiver.c about the assumptions we'd prefer rely to for the GUCs starting a WAL receiver. > So I think adding more of these parameters affecting walreceivers > without coordination is not going quite in the right direction. Indeed. Adding more comments would be one way to prevent the situation to happen here, I fear that others may forget this stuff in the future. -- Michael
signature.asc
Description: PGP signature
