Horton

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

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-24T03:51:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add TAP test for GUC settings passed via CONNECTION in logical replication.

  2. Honor GUC settings specified in CREATE SUBSCRIPTION CONNECTION.

  3. Ensure consistent logical replication of datetime and float8 values.


> On Nov 22, 2025, at 22:14, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Sat, Nov 22, 2025 at 10:31 AM Chao Li <li.evan.chao@gmail.com> wrote:
>> 
>> 
>> 
>>> On Nov 22, 2025, at 00:14, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> 
>>> On Fri, Nov 21, 2025 at 6:24 PM 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:
>>>> 
>>>> ```
>>>> Set a = 1; set b = 2; set c = 3;
>>>> ```
>>>> So that sends a single statement to publisher server, that reduces round-trip from 3 times to one time.
>>> 
>>> 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.
>>> 
>> 
>> No problem. I don’t 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.
> 
> Okay, thanks!
> 
> I've updated the patch to use lengthof() as you suggested.
> The revised version is attached.
> 
> Regards,
> 
> -- 
> 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’s true, then we need to parse user specified options and do some verifications.
>> 
> 
> 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/