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

Fujii Masao <masao.fujii@gmail.com>

From: Fujii Masao <masao.fujii@gmail.com>

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

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-11-21T16:14:04Z

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 →

Add TAP test for GUC settings passed via CONNECTION in logical replication.
- ec8d91c7e78c 15.16 landed
- 67edd54f0639 16.12 landed
- 358784645eb8 17.8 landed
- 6ec596815125 18.2 landed
- 5f13999aa11d 19 (unreleased) landed
Honor GUC settings specified in CREATE SUBSCRIPTION CONNECTION.
- f7eb44e0f087 15.16 landed
- 75f3428f2436 16.12 landed
- 7a990e801a72 17.8 landed
- 797fc5d1b38d 18.2 landed
- d926462d8190 19 (unreleased) landed
Ensure consistent logical replication of datetime and float8 values.
- f3d4019da5d0 15.0 cited

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.

Regards,

-- 
Fujii Masao