On Fri, Jan 28, 2022 at 03:06:57PM +0100, Denis Laxalde wrote: > Julien Rouhaud a écrit : > > I think having a new option for vacuumdb is the right move. > > > > It seems unlikely that any cron or similar on the host will try to run some > > concurrent vacuumdb, but we still have to enforce that only the one > > executed by > > pg_upgrade can succeed. > > > > I guess it could be an undocumented option, similar to postgres' -b, which > > would only be allowed iff --all and --freeze is also passed to be extra > > safe. > > The help text in pg_dump's man page states: > > --binary-upgrade > This option is for use by in-place upgrade > utilities. Its use for other purposes is not > recommended or supported. The behavior of > the option may change in future releases > without notice. > > Is it enough? Or do we actually want to hide it for vacuumdb?
I think it should be hidden, with a comment about it like postmaster.c getopt call: case 'b': /* Undocumented flag used for binary upgrades */ > > > vacuumdb: error: processing of database "postgres" failed: PANIC: cannot > > > make new WAL entries during recovery > > > > Should we tweak that message when IsBinaryUpgrade is true? > > Yes, indeed, I had in mind to simply make the message more generic as: > "cannot insert new WAL entries". -1, it's good to have a clear reason why the error happened, especially since it's supposed to be "should not happen" situation.