From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Krennwallner <tk(at)postsubmeta(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade check for invalid databases |
Date: | 2024-10-07 20:04:22 |
Message-ID: | ZwQ-xtmKbNAz_HK8@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 07, 2024 at 03:37:35PM -0400, Bruce Momjian wrote:
> On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote:
>> Correct, sorry for being unclear. The consistency argument would be to expand
>> pg_upgrade to report all invalid databases rather than just the first found;
>> attempting to fix problems would be a new behavior.
>
> Yes, historically pg_upgrade will fail if it finds anything unusual,
> mostly because what it does normally is already scary enough. If users
> what pg_upgrade to do cleanups, it would be enabled by a separate flag,
> or even a new command-line app.
While I suspect it's rare that someone CTRL-C's out of an accidental DROP
DATABASE and then runs pg_upgrade before trying to recover the data, I
agree with the principle of having pg_upgrade fail by default for things
like this. If we did add a new flag, the new invalid database report that
Daniel mentions could say something like "try again with
--skip-invalid-databases to have pg_upgrade automatically drop invalid
databases."
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-10-07 20:21:19 | Re: Add trim_trailing_whitespace to editorconfig file |
Previous Message | Bruce Momjian | 2024-10-07 19:45:54 | Re: Doc: typo in config.sgml |