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

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'm not really sure that there _is_ a great way to throw an error
report at the right time.  That would require every single output plugin
author to add a function we can call; and every single one of them,
except REPACK, would do nothing.  This seems quite pointless.)

I frankly don't have a problem with letting a transaction spill a few
GBs to disk only to then report an error that pgrepack is being misused.
It's just not something that anyone would do for fun.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/