On Sat, Aug 23, 2025 at 10:23 AM Álvaro Herrera <alvhe...@kurilemu.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 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. > > 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 is not > VACUUM — it is only VACUUM FULL. And we want to make that distinction 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
