On Wed, Nov 19, 2025 at 12:59 AM Fujii Masao <[email protected]> wrote: > > Hi, > > In logical replication, any GUC settings specified in the CONNECTION clause of > CREATE SUBSCRIPTION are currently ignored. For example: > > CREATE SUBSCRIPTION mysub > CONNECTION 'options=''-c wal_sender_timeout=1000''' > PUBLICATION ... > > The wal_sender_timeout value here has no effect. > > This is inconvenient when different logical replication walsenders need > different settings - e.g., a small wal_sender_timeout for walsender > connecting to a nearby subscriber and a larger one for walsender > connecting to a distant subscriber. Right now, it's not easy for users > to control such per-connection behavior. > > The reason of thid limitation is that libpqrcv_connect() always overwrites > the options connection parameter as follows: > > keys[++i] = "options"; > vals[i] = "-c datestyle=ISO -c intervalstyle=postgres -c > extra_float_digits=3"; > > This wipes out any user-specified GUCs in the CONNECTION string. > Physical replication does not have this problem because it does not overwrite > options, so GUCs in primary_conninfo are honored. > > To remove this restriction, how about switching to issuing SET commands for > datestyle, intervalstyle, and extra_float_digits after the connection > is established, > similar to what postgres_fdw does, instead of forcing them into options? > That would allow user-specified GUC settings in CREATE SUBSCRIPTION to > take effect. > > This overwrite behavior was introduced in commit f3d4019da5d and chosen mainly > to avoid extra network round trips according to the discussion [1]. > While SET commands would add a round trip, it only happens at > connection startup, > which is infrequent - so the overhead seems negligible. > > Thoughts?
Attached is a patch implementing this idea. I've also added it to the next CommitFest. Regards, -- Fujii Masao
v1-0001-Honor-GUC-settings-specified-in-CREATE-SUBSCRIPTI.patch
Description: Binary data
