Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CAEze2WhgY_69zxRFLpDUOGXCtJjLEwy4zQZMaPs2Cyz0w+3aNw@mail.gmail.com
Whole thread
In response to Re: Adding REPACK [concurrently]  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Mon, 16 Mar 2026 at 20:34, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2026-Mar-16, Matthias van de Meent wrote:
> > I agree it's not user-friendly, but that's the point of limiting
> > permissions. Users can't install c-functions without SUPERUSER,
> > because it can cause cluster instability and crashes. Users can't
> > create slots without REPLICATION, because they'll be able to
> > negatively impact the whole cluster's performance, and possibly,
> > stability, when taking up replication slots that otherwise would be
> > used for critical HA purposes.
>
> Well, as I said, these repack slots would be separate from the regular
> ones for replication and available only for repack, so they would not
> interfere with the count of slots used for replication, so the second
> point is moot, isn't it?

Sorry, I misread your response as "if at all, then at least like
this", instead of "let's do this alternative in this patch".

But, yes, a pool of slots used exclusively by REPACK CONCURRENTLY
would also solve the slot availability issue.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Read-only connection mode for AI workflows.
Next
From: Melanie Plageman
Date:
Subject: Re: Don't synchronously wait for already-in-progress IO in read stream