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

On 2026-Mar-16, Robert Treat wrote:

> I'm never excited about adding GUCs, but at first thought this seems
> like a decent work-around; most people are unlikely to run multiple
> repack concurrently's, but they can if needed. (I think the most
> likely use case is on clusters using the "database per customer"
> pattern, but if we have the guc, people will have a means to deal with
> it).

I wonder if, longer term, it would make sense to do away with the
max_replication_slots GUC (and this new one) altogether, and use dynamic
shared memory for slots instead.  There's of course always the danger
that people would accumulate arbitrary numbers of slots since they would
never be forced to check.  But that may be a lesser problem than having
to gauge these GUCs with any care.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick."              (Andrew Sullivan)
https://postgr.es/m/20050809113420.GD2768@phlogiston.dyndns.org