Re: Adding REPACK [concurrently]

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Antonin Houska <ah(at)cybertec(dot)at>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2026-03-16 21:45:01
Message-ID: CAEze2WhgY_69zxRFLpDUOGXCtJjLEwy4zQZMaPs2Cyz0w+3aNw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 16 Mar 2026 at 20:34, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2026-03-16 21:45:07 Re: Don't synchronously wait for already-in-progress IO in read stream
Previous Message Bruce Momjian 2026-03-16 21:25:00 Re: Read-only connection mode for AI workflows.