> On Nov 18, 2025, at 23:59, Fujii Masao <masao.fujii@gmail.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?
Before this patch, all user specified options are silently discarded, now all user specified options expect the 3 will
bekept, will that expose a hold where user badly specifies some option that may break logical replication? If that’s
true,then we need to parse user specified options and do some verifications.
I just reviewed v2, and got some comments:
1.
```
+ char sql[100];
```
Hardcode 100 here doesn’t look good. If you decide to keep, I won’t have a strong objection.
2
```
+ const char *params[] =
+ {"datestyle", "intervalstyle", "extra_float_digits", NULL};
+ const char *values[] = {"ISO", "postgres", "3", NULL};
```
Nit: we don’t need to have a NULL terminator element. We can use lengthof() macro to get array length. lengthof() is
definedin c.h.
3. To minimize the network round-trip, maybe we can combine the 3 set into a single statement?
4. The commit message:
```
This commit removes the restriction by changing how logical replication
connections are established so that GUC settings in the CONNECTION string
are properly passed through to and uesd by the walsender. This enables
```
This is a little bit inaccurate, all user specified settings expected the 3 ones being overwritten will be honored.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
