pg_utility ?

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Christoph Berg <myon(at)debian(dot)org>
Subject: pg_utility ?
Date: 2025-11-04 17:52:19
Message-ID: 202511041739.bixo76pkku7h@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

One of the things that came up during the pgconf.eu talk about REPACK,
proposed by Christoph Berg, is that adding another utility pg_repackdb
to run it from the command line adds more noise to an already noisy tool
neighbourhood. He asked, how about we instead add a generic tool to run
utility commands? So the user would be able to do things such as

pg_utility vacuum -t tab1 -t tab2 # what vacuumdb does
pg_utility analyze -t tab1 -t tab2 # what vacuumdb -Z does
pg_utility vacuum analyze -t tab1 -t tab2 # what vacuumdb -z does
pg_utility cluster -t tab1 -t tab2 # what clusterdb does
pg_utility reindex -t tab1 -t tab2 # what reindexdb does

Each such tool would retain more or less its current behavior, i.e., its
ability to run things in parallel, to discover tables to operate on
based on circumstances, to silently ignore objects depending on the user
lacking specific privilege bits, and so on.

This way, instead of an entire pg_repackdb tool, we would add just a new
mode to pg_utility:

pg_utility repack -t tab1 -t tab2 # what pg_repackdb would do

Christoph, can you please confirm that this is approximately what you
had in mind? Other names are of course possible.

I didn't immediately love this idea, but I'm not totally opposed to it
either, and perhaps it makes things better rather than adding yet
another very narrowly-focused tool. Also, pg_ctl already kinda has a
somewhat similar facet with its "pg_ctl init" mode.

Thanks

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Once again, thank you and all of the developers for your hard work on
PostgreSQL. This is by far the most pleasant management experience of
any database I've worked on." (Dan Harris)
http://archives.postgresql.org/pgsql-performance/2006-04/msg00247.php

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2025-11-04 17:59:34 Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement
Previous Message Jeff Davis 2025-11-04 17:51:18 Re: Fix redundant memset after palloc0 in heap_form_minimal_tuple()