Hi,
On Tue, Sep 22, 2026 at 1:52 PM Euler Taveira <euler@eulerto.com> wrote:
>
> On Tue, Sep 22, 2026, at 1:25 PM, Nathan Bossart wrote:
> > On Tue, Sep 22, 2026 at 09:10:44AM -0700, Bharath Rupireddy wrote:
> >> 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.
>
> ... or add a detailed error message to pg_upgrade saying that autovacuum or a
> custom worker will remove the invalid databases in the next round. I don't like
> the idea of having duplicate functionality. You might have to deal with a race
> condition if pg_upgrade and autovacuum decide to act at the same time.
Thanks for looking. IMHO, this isn't duplicate functionality. When
implemented, core would drop the invalid databases. The proposal in
this thread only makes pg_upgrade skip them instead of failing the
upgrade.
The autovacuum launcher isn't started in binary upgrade mode, so there
is no race with pg_upgrade. A custom worker (if chosen over the
autovacuum launcher) can do the same.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
