Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Adding REPACK [concurrently]
Date
Msg-id ce28f0b5-5010-4032-8e92-8398f1db4ce6@app.fastmail.com
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: Adding REPACK [concurrently]
List pgsql-hackers
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].

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.


[1] https://www.postgresql.org/message-id/CAJgfmqXYYKXR%2BQUhEa3cq6pc8dV0Hu7QvOUccm7R0TkC%3DT-%2B%3DA%40mail.gmail.com


--
Euler Taveira
EDB   https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: e3718e7@tutamail.com
Date:
Subject: [PATCH] Add Hebrew and Arabic combining characters to unaccent.rules
Next
From: Sami Imseih
Date:
Subject: Re: Improve LWLock tranche name visibility across backends