Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect

On Wed, Nov 19, 2025 at 12:59 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> 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