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

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 shou=
ld 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 vacuum=
db.  But the rest of the vacuumdb behavior must stay, I think, because R=
EPACK is not VACUUM =E2=80=94 it is only VACUUM FULL. And we want to mak=
e that distinction very clear.

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

--=20
=C3=81lvaro Herrera