public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Fujii Masao <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
Date: Thu, 20 Nov 2025 14:53:49 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com>
References: <CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com>



> On Nov 18, 2025, at 23:59, 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?

Before this patch, all user specified options are silently discarded, now all user specified options expect the 3 will be kept, 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 defined in 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/

view thread (37+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox