Re: Adding REPACK [concurrently]
От | Euler Taveira |
---|---|
Тема | Re: Adding REPACK [concurrently] |
Дата | |
Msg-id | ce28f0b5-5010-4032-8e92-8398f1db4ce6@app.fastmail.com обсуждение исходный текст |
Ответ на | Re: Adding REPACK [concurrently] (Álvaro Herrera <alvherre@kurilemu.de>) |
Ответы |
Re: Adding REPACK [concurrently]
|
Список | 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 по дате отправления: