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

Srinath Reddy Sadipiralla <srinath2133@gmail.com>

From: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
To: Antonin Houska <ah@cybertec.at>
Cc: alvherre@kurilemu.de, n.kalinin@postgrespro.ru, pgsql-bugs@lists.postgresql.org, b@ida.kurilemu.internal
Date: 2026-06-03T10:25:18Z
Lists: pgsql-bugs

Attachments

On Wed, Jun 3, 2026 at 1:00 PM Antonin Houska <ah@cybertec.at> 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.
>

cool ... that's cleaner, incorporated these changes and added test
,errcode.


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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Disallow direct use of the pgrepack logical decoding plugin