public inbox for [email protected]  

help / color / mirror / Atom feed

From: Srinath Reddy Sadipiralla <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API
Date: Fri, 5 Jun 2026 11:39:03 +0530
Message-ID: <CAFC+b6q6v+3jwcrZRO-dqj4KXy6uGaxi7qwoOC0cOOD5DeJn3Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <33766.1780471821@localhost>
	<[email protected]>

On Thu, Jun 4, 2026 at 2:50 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'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.
>

makes sense, we can go with your approach, thanks for
the clarification.


-- 
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

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]
  Subject: Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API
  In-Reply-To: <CAFC+b6q6v+3jwcrZRO-dqj4KXy6uGaxi7qwoOC0cOOD5DeJn3Q@mail.gmail.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