vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases - Mailing list pgsql-hackers

From Nathan Bossart
Subject vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
Date
Msg-id 20230628232402.GA1954626@nathanxps13
Whole thread Raw
Responses Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to process in all databases
List pgsql-hackers
While working on some other patches, I found myself wanting to use the
following command to vacuum the catalogs in all databases in a cluster:

    vacuumdb --all --schema pg_catalog

However, this presently fails with the following error:

    cannot vacuum specific schema(s) in all databases

AFAICT there no technical reason to block this, and the resulting behavior
feels intuitive to me, so I wrote 0001 to allow it.  0002 allows specifying
tables to process in all databases in clusterdb, and 0003 allows specifying
tables, indexes, schemas, or the system catalogs to process in all
databases in reindexdb.

I debated also allowing users to specify different types of objects in the
same command (e.g., "vacuumdb --schema myschema --table mytable"), but it
looked like this would require a more substantial rewrite, and I didn't
feel that the behavior was intuitive.  For the example I just gave, does
the user expect us to process both the "myschema" schema and the "mytable"
table, or does the user want us to process the "mytable" table in the
"myschema" schema?  In vacuumdb, this is already blocked, but reindexdb
accepts combinations of tables, schemas, and indexes (yet disallows
specifying --system along with other types of objects).  Since this is
inconsistent with vacuumdb and IMO ambiguous, I've restricted such
combinations in 0003.

Thoughts?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add GUC to tune glibc's malloc implementation.
Next
From: Andres Freund
Date:
Subject: Re: Changing types of block and chunk sizes in memory contexts