Message-ID: <68a9660d.df0a0220.22e722.840c@mx.google.com>
Sender: Michael Banck <mbanck@gmail.com>
Date: Sat, 23 Aug 2025 08:56:12 +0200
From: Michael Banck <mbanck@gmx.net>
To: Euler Taveira <euler@eulerto.com>
Cc: =?iso-8859-1?Q?=C1lvaro?= Herrera <alvherre@kurilemu.de>,
	Robert Treat <rob@xzilla.net>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>,
	Antonin Houska <ah@cybertec.at>,
	Fujii Masao <masao.fujii@gmail.com>,
	Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Subject: Re: Adding REPACK [concurrently]
References: <202508220940.u6qkixbhu7xs@alvherre.pgsql>
 <ce28f0b5-5010-4032-8e92-8398f1db4ce6@app.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ce28f0b5-5010-4032-8e92-8398f1db4ce6@app.fastmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/68a9660d.df0a0220.22e722.840c%40mx.google.com>
Precedence: bulk

Hi,

On Fri, Aug 22, 2025 at 05:32:34PM -0300, Euler Taveira wrote:
> On Fri, Aug 22, 2025, at 6:40 AM, Álvaro Herrera wrote:
> > On 2025-Aug-21, Robert Treat wrote:
> >> What's the plan for clusterdb? It seems like we'd ideally create a
> >> stand alone pg_repackdb which replaces clusterdb and also allows us to
> >> remove the FULL options from vacuumdb.
> >
> > I don't think we should remove clusterdb, to avoid breaking any scripts
> > that work today.  As you say, I would create the standalone pg_repackdb
> > to do what we need it to do (namely: run the REPACK commands) and leave
> > vacuumdb and clusterdb alone.  Removing the obsolete commands and
> > options can be done in a few years.
> 
> I would say that we need to plan the removal of these binaries (clusterdb and
> vacuumdb). We can start with a warning into clusterdb saying they should use
> pg_repackdb. In a few years, we can remove clusterdb. There were complaints
> about binary names without a pg_ prefix in the past [1].

Yeah.
 
> 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 should 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.


Michael