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: Alvaro Herrera <alvherre@kurilemu.de>
Cc: Antonin Houska <ah@cybertec.at>, n.kalinin@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2026-06-05T06:09:03Z
Lists: pgsql-bugs
On Thu, Jun 4, 2026 at 2:50 AM Alvaro Herrera <alvherre@kurilemu.de> wrote: > 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. > makes sense, we can go with your approach, thanks for the clarification. -- 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 →
-
Disallow direct use of the pgrepack logical decoding plugin
- cd7b204b2df9 19 (unreleased) landed