MIME-Version: 1.0
References: <202508220940.u6qkixbhu7xs@alvherre.pgsql>
 <ce28f0b5-5010-4032-8e92-8398f1db4ce6@app.fastmail.com>
 <68a9660d.df0a0220.22e722.840c@mx.google.com>
 <1764804a-2bc1-46e9-9008-82ea39cb8c81@app.fastmail.com>
In-Reply-To: <1764804a-2bc1-46e9-9008-82ea39cb8c81@app.fastmail.com>
From: Robert Treat <rob@xzilla.net>
Date: Mon, 25 Aug 2025 12:03:03 -0400
Message-ID: 
 <CAJSLCQ29e9C32-1pjsKRedmu=nsuS2nDSii-=D9mh3mYDhr6OA@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
Cc: Michael Banck <mbanck@gmx.net>, Euler Taveira <euler@eulerto.com>,
	pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
 Antonin Houska <ah@cybertec.at>,
	Fujii Masao <masao.fujii@gmail.com>,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJSLCQ29e9C32-1pjsKRedmu%3DnsuS2nDSii-%3DD9mh3mYDhr6OA%40mail.gmail.com>
Precedence: bulk

On Sat, Aug 23, 2025 at 10:23=E2=80=AFAM =C3=81lvaro Herrera <alvherre@kuri=
lemu.de> wrote:
> On 2025-08-23, Michael Banck wrote:
> > On Fri, Aug 22, 2025 at 05:32:34PM -0300, Euler Taveira wrote:
>
> >> I don't think we need to keep vacuumdb. Packagers can keep a symlink (=
vacuumdb)
> >> to pg_repackdb. We can add a similar warning message saying they shoul=
d use
> >> pg_repackdb if the symlink is used.
> >
> > Unless pg_repack has the same (or a superset of) CLI and behaviour as
> > vacuumdb (I haven't checked, but doubt it?), I think replacing vacuumdb
> > with a symlink to pg_repack will lead to much more breakage in existing
> > scripts/automation than clusterdb, which I guess is used orders of
> > magnitude less frequently than vacumdb.
>
> Yeah, I completely disagree with the idea of getting rid of vacuumdb. We =
can, maybe, in a distant future, get rid of the --full option to vacuumdb. =
 But the rest of the vacuumdb behavior must stay, I think, because REPACK i=
s not VACUUM =E2=80=94 it is only VACUUM FULL. And we want to make that dis=
tinction very clear.
>

Or to put it the other way, VACUUM FULL is not really VACUUM either,
it is really a form of "repack".

> We can also, in a few years, get rid of clusterdb.  But I don't think we =
need to deprecate it just yet.
>

Yeah, ISTM the long term goal should be two binaries, one of which
manages aspects of clustering/repacking type of activities, and one
which manages vacuum type activities. I don't think that's different
that what Alvaro is proposing, FWIW my original question was about
confirming that was the end goal, but also trying to understand the
coordination of when these changes would take place, because the
changes to the code, changes to the SQL commands and their docs, and
changes to the command line tools, seem to be working at different
cadences. Which can be fine if it's on purpose, but maybe needs to be
tightened up if not; for example, the current patchset doesn't make
any changes to clusterdb, which one might expect to emit a warning
about being deprecated in favor of pg_repackdb, if not just a complete
punting to use pg_repackdb instead.

Robert Treat
https://xzilla.net