Date: Thu, 29 Jun 2023 13:56:38 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: vacuumdb/clusterdb/reindexdb: allow specifying objects to
 process in all databases
Message-ID: <20230629205638.GA2054380@nathanxps13>
References: <20230628232402.GA1954626@nathanxps13>
 <20230629.141626.886053266048932185.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230629.141626.886053266048932185.horikyota.ntt@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230629205638.GA2054380%40nathanxps13>
Precedence: bulk

Thanks for taking a look.

On Thu, Jun 29, 2023 at 02:16:26PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart <nathandbossart@gmail.com> wrote in 
>> 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
> 
> I think spcyfying the two at once is inconsistent if we maintain the
> current behavior of those options.
> 
> It seems to me that that change clearly modifies the functionality of
> the options. As a result, those options look like restriction
> filters. For example, "vacuumdb -s s1_* -t t1" will vacuum all table
> named "t1" in all schemas matches "s1_*".

Sorry, I'm not following.  I intentionally avoided allowing combinations of
--schema and --table in the patches I sent.  This is the current behavior
of vacuumdb.  Are you suggesting that they should be treated as restriction
filters?

> While I think this is useful, primarily for system catalogs, I'm not
> entirely convinced about its practicality to user objects. It's
> difficult for me to imagine that a situation where all databases share
> the same schema would be major.
> 
> Assuming this is used for user objects, it may be necessary to safely
> exclude databases that lack the specified schema or table, provided
> the object present in at least one other database. But the exclusion
> should be done with printing some warnings.  It could also be
> necessary to safely move to the next object when reindex or cluster
> operation fails on a single object due to missing prerequisite
> situations. But I don't think we might want to add such complexity to
> these "script" tools.

Perhaps we could add something like a --skip-missing option.

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