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

From Alvaro Herrera
Subject Re: Adding REPACK [concurrently]
Date
Msg-id 202603161503.oft3hnonplyi@alvherre.pgsql
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Adding REPACK [concurrently]
Re: Adding REPACK [concurrently]
List pgsql-hackers
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)



pgsql-hackers by date:

Previous
From: "zengman"
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Next
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query