Re: Teach pg_upgrade to deal with invalid databases - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Teach pg_upgrade to deal with invalid databases
Date
Msg-id arKsC91KV1cTUfDS@nathan
Whole thread
In response to Re: Teach pg_upgrade to deal with invalid databases  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Teach pg_upgrade to deal with invalid databases
List pgsql-hackers
On Tue, Sep 22, 2026 at 09:10:44AM -0700, Bharath Rupireddy wrote:
> I have a WIP proposal to automatically drop invalid databases in core.
> The idea is to use a dynamic bg worker launched by the autovacuum
> launcher when it loops over all databases and detects them. It could
> be the autovacuum launcher itself doing the drop, or another bg
> worker, or a new custodian process like
> https://postgr.es/m/C1EE64B0-D4DB-40F3-98C8-0CED324D34CB@amazon.com,
> but more on which process does this in a separate thread that I plan
> to start.

Maybe I should try to revive the custodian worker for v20...

> Even if core drops them automatically, having pg_upgrade deal with
> them is useful on its own IMHO, since the upgrade could start before
> that happens. So, I prefer pg_upgrade skipping them without any
> option, emitting info about the skipped ones, which will not happen
> often in practice once core handles the drop.

Yeah, I think we should do both.  Automatic deletion is probably the best
thing to do to handle leftover invalid databases, but as you say we can't
rely on that happening before someone upgrades.

-- 
nathan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Catversion bumps during beta (was Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring)
Next
From: Nathan Bossart
Date:
Subject: Re: run pgindent in CI