Feedback-ID: ia2694551:Fastmail
Date: Mon, 16 Mar 2026 16:10:46 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>,
	Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
 Pg Hackers <pgsql-hackers@lists.postgresql.org>,
	Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Message-ID: <202603161503.oft3hnonplyi@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAEze2WiA-4EZ5Pfnr6Gw-2VGqq528_jJR=vCHNBEWoOA2vR4rg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202603161503.oft3hnonplyi%40alvherre.pgsql>
Precedence: bulk

On 2026-Mar-16, Matthias van de Meent wrote:

> Note that most of my argument hinges on the impact on other, unrelated
> databases/tables/sessions. Replication slots have a hard cap defined
> at startup, and effective_wal_level increases the WAL generated by
> practically all backends.

I'd rather have a new GUC to declare a bunch of additional slots that
are reserved exclusively for repack, set its default to something like
3, and call it a day.  If all repack slots are in use, you don't get to
run repack, period.

A slot costs nothing if unused, and we really don't want to make the
interaction with regular replication more complicated than it is today.

> However, we don't live in that world, so I am opposed to allowing
> table owners without REPLICATION to take any/all replication slots.

I think requiring REPACK users to have the REPLICATION priv is rather
user unfriendly.  Some potential REPACK users might not have any other
use for replication at all.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"World domination is proceeding according to plan"        (Andrew Morton)