RE: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API

On Thursday, June 4, 2026 5:03 AM Alvaro Herrera <alvherre@kurilemu.de> wrote:
> On 2026-Jun-03, Antonin Houska wrote:
> 
> > Srinath Reddy Sadipiralla <srinath2133@gmail.com> 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