| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |
| Date: | 2025-11-22 14:14:27 |
| Message-ID: | CAHGQGwEeJ6ijS=d5byU0Pq1J9YYGw+X=fyomd_d71sx5NOHdsA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Nov 22, 2025 at 10:31 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>
>
> > On Nov 22, 2025, at 00:14, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >
> > On Fri, Nov 21, 2025 at 6:24 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Honor-GUC-settings-specified-in-CREATE-SUBSCRIPTI.patch | application/octet-stream | 3.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2025-11-22 14:16:44 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |
| Previous Message | Mihail Nikalayeu | 2025-11-22 14:06:00 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |