Re: Adding REPACK [concurrently]

From: Robert Treat <rob(at)xzilla(dot)net>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
Subject: Re: Adding REPACK [concurrently]
Date: 2025-08-21 22:06:13
Message-ID: CAJSLCQ1YvjRvjji29dNMiYy+JnseMZkDpx4Ui0zcpLdk8wviyg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 19, 2025 at 2:53 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> Note choice of shell command name: though all the other programs in
> src/bin/scripts do not use the "pg_" prefix, this one does; we thought
> it made no sense to follow the old programs as precedent because there
> seems to be a lament for the lack of pg_ prefix in those, and we only
> keep what they are because of their long history. This one has no
> history.
>
> Still on pg_repackdb, the implementation here is to install a symlink
> called pg_repackdb which points to vacuumdb, and make the program behave
> differently when called in this way. The amount of additional code for
> this is relatively small, so I think this is a worthy technique --
> assuming it works. If it doesn't, Antonin proposed a separate binary
> that just calls some functions from vacuumdb. Or maybe we could have a
> common source file that both utilities call.
>

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.

Robert Treat
https://xzilla.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-08-21 22:25:34 Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Previous Message KAZAR Ayoub 2025-08-21 19:36:42 Re: Speed up COPY FROM text/CSV parsing using SIMD