Horton
Menu

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

Antonin Houska <ah@cybertec.at>

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

Attachments

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.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.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