On Sun, Oct 4, 2026 at 8:00 PM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Fri, Oct 2, 2026 at 9:21 AM Nathan Bossart <[email protected]> > wrote: > > > > On Thu, Sep 24, 2026 at 08:37:00AM -0700, Bharath Rupireddy wrote: > > > I implemented the above approach, pg_upgrade skipping them without any > > > option and emitting info about the skipped ones. I ensured the CI is > > > happy. Please find the attached v2 patch. > > > > Thanks. IMHO we shouldn't bother adding a note to pg_upgrade's > > documentation, or even emitting warnings when pg_upgrade skips invalid > > databases. For all intents and purposes, the database is already dropped > > (for some definition of "dropped"), and there's nothing actionable for the > > user. > > Thanks for looking at it. > > Upon thinking more on this, I agree on both. Unless there are > objections, I will drop the warning and the doc note in the next > version. > > Once pg_upgrade skips invalid databases, the user has no action to > take. Even if the user reverts to the old cluster, the invalid > databases are still there. > > I also think not reporting them matches what other tools do, like > pg_dumpall (dumpDatabases()), vacuumdb (vacuum_all_databases()), > reindexdb (reindex_all_databases()), etc. They skip invalid databases > without emitting any info, and their docs don't mention it either. >
I guess I don't object, but it feels a little odd to make a user visible behavioral change without giving any kinds of heads up; this would have errored out in previous versions, now it "just works", but just works might look concerning if a database that used to show up in your database list now goes missing, or you are wondering why your cluster size dropped significantly after upgrade. There are some other weird corner cases that might come up too, but hopefully the release note entry will be enough for people looking for explanations. Robert Treat https://xzilla.net
