Re: pg_upgrade check for invalid databases

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Thomas Krennwallner <tk(at)postsubmeta(dot)net>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade check for invalid databases
Date: 2024-10-25 11:55:57
Message-ID: 73789C01-815C-4BA3-B484-DB63849513A6@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 14 Oct 2024, at 18:57, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> What might be acceptable would be to add an option that would make
> pg_upgrade more tolerant of problems in many areas, that is a lot more
> research and discussion.

I agree that the concept of having pg_upgrade perform (opt-in) skipping and/or
repairs of the old cluster warrants a larger discussion in its own thread.
There has been significant amount of energy spent recently to add structure to
the checks, any new feature should be properly designed for the get-go.

In the meantime, the OP has a good point that it's a tad silly that pg_upgrade
fails hard on invalid databases instead of detecting and reporting like how
other errors are handled. The attached adds this check and expands the report
wording to cover it.

--
Daniel Gustafsson

Attachment Content-Type Size
0001-Find-invalid-databases-during-upgrade-check-stage.patch application/octet-stream 5.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-10-25 11:56:36 Re: pgsql: Implement pg_wal_replay_wait() stored procedure
Previous Message Yasir 2024-10-25 11:05:14 Re: Alias of VALUES RTE in explain plan