On 10/6/26 11:41 AM, Khoa Nguyen wrote:
Traditionally, databases are large and hosted in silos serving
critical applications. These critical-application requirements are
still there but I'm starting to see more databases being hosted on the
same cluster for the purpose of lower resource overhead. These are
generally AI produced tools/applications/reports running on cron jobs
that do need persistent stores. I have not seen the scale of 5,000+
databases as mentioned in Parallelizing startup with many databases
but I'm seeing the requirement for co-location increasing. This
proposed command option can definitely help when working with
multi-database clusters.

I think this is a useful addition to vacuumdb and I hope we can get it
through.  Please let me know if I can be of any assistance.

-Khoa

On Thu, Jun 18, 2026 at 9:36 AM Khoa Nguyen <[email protected]> wrote:

On Wed, Jun 17, 2026 at 7:24 PM Ben Mejia
<[email protected]> wrote:

I think that the behavior of this patch that silently ignores --exlcude-database 
"non-existent-db" is broken. What if someone has a large database "my-db-name", 
and they misspell it:

$ vacuumdb --all --exclude-database "my-dbname"

This will kick off a vacuum including the "my-db-name" they were trying to 
exclude.

I think it would be better to generate an error and not do anything in this 
case.
+1

Since exclude-schema validates and stops on error, I think it would
make sense to do the same for exclude-database.  Current users are
used to this behavior so it's best to keep it consistent.


This also tracks with vacuumdb's existing behavior on --table/--schema which 
will tell you about a typo.

Mohamed,

If you'd like, I can assume authorship of this patch and post it to the current CF.

Let me know...

-Ben Mejia


Reply via email to