Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
| От | Chao Li |
|---|---|
| Тема | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Дата | |
| Msg-id | 313C50E8-E05A-4A64-95FF-C9DC5A70ECD7@gmail.com обсуждение исходный текст |
| Ответ на | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect (Fujii Masao <masao.fujii@gmail.com>) |
| Ответы |
Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect
|
| Список | pgsql-hackers |
> 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 optionthat 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/
В списке pgsql-hackers по дате отправления: