Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take
 effect
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAHGQGwEeJ6ijS=d5byU0Pq1J9YYGw+X=fyomd_d71sx5NOHdsA@mail.gmail.com>
Date: Mon, 24 Nov 2025 11:51:58 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <313C50E8-E05A-4A64-95FF-C9DC5A70ECD7@gmail.com>
References: 
 <CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com>
 <F7704488-8AE1-4744-AF8C-51181BAA631A@gmail.com>
 <CAHGQGwGYG09DZnx7VVFvr7EfpC12sf+36D6iCSSAFMj66RY2_Q@mail.gmail.com>
 <6E35E0EF-A842-408A-A264-DB6D428C2BD6@gmail.com>
 <CAHGQGwGnkM8aYtxYAHXRPWYe90fbypz5TMezHDiy0Jt8=+BPpQ@mail.gmail.com>
 <726A237D-D1C1-49E5-99A0-AC5899897DA6@gmail.com>
 <CAHGQGwEeJ6ijS=d5byU0Pq1J9YYGw+X=fyomd_d71sx5NOHdsA@mail.gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/313C50E8-E05A-4A64-95FF-C9DC5A70ECD7%40gmail.com>
Precedence: bulk


> On Nov 22, 2025, at 22:14, Fujii Masao <masao.fujii@gmail.com> wrote:
>=20
> On Sat, Nov 22, 2025 at 10:31=E2=80=AFAM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>=20
>>=20
>>=20
>>> On Nov 22, 2025, at 00:14, Fujii Masao <masao.fujii@gmail.com> =
wrote:
>>>=20
>>> On Fri, Nov 21, 2025 at 6:24=E2=80=AFPM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>>> No, what I was thinking is that, we could combine the three set =
statement into one, like:
>>>>=20
>>>> ```
>>>> Set a =3D 1; set b =3D 2; set c =3D 3;
>>>> ```
>>>> So that sends a single statement to publisher server, that reduces =
round-trip from 3 times to one time.
>>>=20
>>> I see the point about combining the three SET commands to reduce =
round trips,
>>> but I think the current approach in the patch (i.e., issuing a =
separate
>>> SET command for each parameter) is sufficient. I still don't think
>>> the additional round trip during replication connection startup is
>>> a real concern. This approach is also consistent with what =
postgres_fdw
>>> and pg_dump already do.
>>>=20
>>=20
>> No problem. I don=E2=80=99t have a strong option here. I just saw you =
mentioned overhead of round trip and thought to improve. But I agree =
that overhead is tiny, not a real concern.
>=20
> Okay, thanks!
>=20
> I've updated the patch to use lengthof() as you suggested.
> The revised version is attached.
>=20
> Regards,
>=20
> --=20
> Fujii Masao
> <v3-0001-Honor-GUC-settings-specified-in-CREATE-SUBSCRIPTI.patch>

V3 looks good to me.


>> 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=E2=80=99s true, then we need to parse user =
specified options and do some verifications.
>>=20
>=20
> Yeah, I agree that if certain GUCs can break logical replication,
> we should enforce "safe" values, just as we currently do for =
datestyle.
> And if any other GUCs can cause the issue, they could affect
> postgres_fdw etc, so the fix would need to be broader.

Just want to clarify if you mean you will handle this in a future patch?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/