public inbox for [email protected]  

help / color / mirror / Atom feed

From: Alvaro Herrera <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Srinath Reddy Sadipiralla <[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: Wed, 3 Jun 2026 23:02:56 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <33766.1780471821@localhost>

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.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  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: <[email protected]>

* 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