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
