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?
While at it:
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".
