Re: Teach pg_upgrade to deal with invalid databases

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Euler Taveira <euler(at)eulerto(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Rithvika Devisetti <devisettirithvika(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Teach pg_upgrade to deal with invalid databases
Date: 2026-09-22 21:12:11
Message-ID: CALj2ACUv9b_FWyO7OuNo75XXKDcqhwtwb8_anOynyDNiUrFrxw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Sep 22, 2026 at 1:52 PM Euler Taveira <euler(at)eulerto(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-09-22 21:20:30 Re: Add REPACK progress phases for logical decoding setup
Previous Message Zsolt Parragi 2026-09-22 21:01:04 Re: Crashes on a partition whose concurrent detach never finished