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: Jelte Fennema-Nio <postgres@jeltef.nl>

Cc: Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-11-25T11:32:51Z

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 Mon, Nov 24, 2025 at 2:55 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>
> On Fri, Nov 21, 2025, 00:47 Fujii Masao <masao.fujii@gmail.com> wrote:
>>
>> On Thu, Nov 20, 2025 at 3:54 PM Chao Li <li.evan.chao@gmail.com> wrote:
>> > Before this patch, all user specified options are silently discarded,
>>
>> The GUC settings in CREATE SUBSCRIPTION were honored up through v14;
>> the behavior changed in commit f3d4019da5d, so some might view this
>> as a regression.
>
>
> FWIW, I definitely view it as a regression. I used this in citus to make the logical replication sender of the shard rebalancer use a higher CPU priority[1]. I had no clue, until now, that that logic got completely broken in PG15 (which we coincidentally added support for in the same release).

Thanks for sharing this!


> I'm not entirely sure if it's worth a backpatch. This citus feature probably isn't the most critical. So if that's the only usecase in the wild that got broken, then that might be fine. But I at least wanted to share that others (i.e. me) have used this feature.

I found the following description in logical replication docs, which makes me
start thinking that the patch would need to be backpatched.

-----------------
If the role does not trust all table owners, include options=-crow_security=off
in the connection string
https://www.postgresql.org/docs/devel/logical-replication-security.html
-----------------

Regards,

-- 
Fujii Masao