Re: Adding REPACK [concurrently]

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)