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

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, 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-24 05:54:54
Message-ID: CAGECzQS8BQh22BMfR+h3+zaiaJvQMMr96nXuiRrgdWoshucc_A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 21, 2025, 00:47 Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Thu, Nov 20, 2025 at 3:54 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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).

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.

[1]:
https://github.com/citusdata/citus/blame/662b7248db2146d33a1a21227271b839355a970a/src/backend/distributed/replication/multi_logical_replication.c#L1510

>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2025-11-24 06:03:47 Re: SQL Property Graph Queries (SQL/PGQ)
Previous Message shveta malik 2025-11-24 05:53:56 Re: How can end users know the cause of LR slot sync delays?