Re: Teach pg_upgrade to deal with invalid databases

On Sun, Oct 4, 2026 at 8:00 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Fri, Oct 2, 2026 at 9:21 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> 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