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

On Mon, 16 Mar 2026 at 21:33, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> 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
>
>

Hi all,
I was reading this thread and was doing some tests.

postgres=# create table test1(a int);
CREATE TABLE
postgres=# create table test2(a int);
CREATE TABLE
postgres=# vacuum full test1 , test2;
VACUUM
postgres=# repack test1;
REPACK
postgres=# repack test2;
REPACK
postgres=# repack test1, test2;
ERROR:  syntax error at or near ","
LINE 1: repack test1, test2;
                    ^