Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch

On Sun, Jun 05, 2022 at 09:24:25AM +0900, Michael Paquier wrote:
> Well, another error that could happen in the early code paths is
> EACCES on a custom socket directory specified, and we'd still face the
> same problem on a follow-up restart.  Using a sub-directory structure
> as Daniel and Tom mention would address all that (if ignoring EEXIST
> for the BASE_OUTPUTDIR), removing any existing content from the base
> path when not using --retain.  This comes with the disadvantage of
> bloating the disk on repeated errors, but this last bit would not
> really be a huge problem, I guess, as it could be more useful to keep
> the error information around.

I have been toying with the idea of a sub-directory named with a
timestamp (Unix time, like log_line_prefix's %n but this could be
any format) under pg_upgrade_output.d/ and finished with the
attached.  The logs are removed from the root path when --check is
used without --retain, like for a non-check command.  I have added a
set of tests to provide some coverage for the whole:
- Failure of --check where the binary path does not exist, and
pg_upgrade_output.d/ is not removed.
- Follow-up run of pg_upgrade --check, where pg_upgrade_output.d/ is
removed.
- Check that pg_upgrade_output.d/ is also removed after the main
upgrade command completes.

The logic in charge of cleaning up the logs has been moved to a single
routine, aka cleanup_logs().

Thoughts?
--
Michael