public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zhijie Hou (Fujitsu) <[email protected]>
To: Alvaro Herrera <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: RE: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API
Date: Fri, 5 Jun 2026 08:08:07 +0000
Message-ID: <TY4PR01MB17718C5A3450599FB1C6DFA5A94112@TY4PR01MB17718.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <[email protected]>
References: <33766.1780471821@localhost>
<[email protected]>
On Thursday, June 4, 2026 5:03 AM Alvaro Herrera <[email protected]> wrote:
> On 2026-Jun-03, Antonin Houska wrote:
>
> > Srinath Reddy Sadipiralla <[email protected]> wrote:
> >
> > > Could we reject the pgrepack plugin at slot creation instead, in
> > > pg_create_logical_replication_slot() and the CREATE_REPLICATION_SLOT
> > > command, so misuse gets a clear "reserved for REPACK
> (CONCURRENTLY)"
> > > error up front, before any decoding? REPACK creates its slot
> > > directly via ReplicationSlotCreate(), so it's unaffected, and the
> > > begin-callback check with magic guard can stay as the internal safety net.
> > > Happy to be told this isn't worth special-casing :)
> >
> > Another possible approach: restrict the use of the plugin to the
> > REPACK decoding worker.
>
> I don't like either of these approaches, because they are forcing the generic
> facility (either slot creation or logical decoding setup) to know something
> about one specific user of the facility. That is to say, the restriction is being
> added on the wrong side of the abstraction.
> I know my implementation the drawback you (Srinath) mentioned, because
> the abstraction doesn't provide us with a great way to inject an error report at
> the exact spot we need it; but I think it's at the correct side of the abstraction.
I have no objection to the proposed approach. But I would like to confirm
whether reporting an ERROR in the startup callback (when the context is not a
REPACK decoding worker) is considered acceptable.
Like:
repack_startup(LogicalDecodingContext *ctx, OutputPluginOptions *opt,
bool is_init)
...
if (!AmRepackWorker())
ereport(ERROR,
errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("this plugin can only be used by REPACK (CONCURRENTLY)"));
Best Regards,
Hou zj
view thread (14+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API
In-Reply-To: <TY4PR01MB17718C5A3450599FB1C6DFA5A94112@TY4PR01MB17718.jpnprd01.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox