Re: pg_upgrade check for invalid databases
От | Daniel Gustafsson |
---|---|
Тема | Re: pg_upgrade check for invalid databases |
Дата | |
Msg-id | FEEF07B8-CA99-45E2-A746-8A9E980C82AB@yesql.se обсуждение исходный текст |
Ответ на | Re: pg_upgrade check for invalid databases (Nathan Bossart <nathandbossart@gmail.com>) |
Список | pgsql-hackers |
> On 7 Oct 2024, at 22:04, Nathan Bossart <nathandbossart@gmail.com> wrote: > > 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." If we are teaching pg_upgrade to handle errors, either by skipping or by fixing, then I believe this is the right way to go about it. A successful run should probably also create a report of the databases which were skipped. -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: