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

On Fri, Jun 03, 2022 at 10:32:27PM -0500, Justin Pryzby wrote:
> On Sat, Jun 04, 2022 at 12:13:19PM +0900, Michael Paquier wrote:
>> I am not so sure.  My first reaction was actually to bypass the
>> creation of the directories on EEXIST.
> 
> But that breaks the original motive behind the patch I wrote - logfiles are
> appended to, even if they're full of errors that were fixed before re-running
> pg_upgrade.

Yep.

>> But, isn't the problem different and actually older here?  In the set of
>> commands given by Tushar, he uses the --check option without --retain, but
>> the logs are kept around after the execution of the command.  It seems to me
>> that there is an argument for also removing the logs if the caller of the
>> command does not want to retain them.
> 
> You're right that --check is a bit inconsistent, but I don't think we could
> backpatch any change to fix it.  It wouldn't matter much anyway, since the
> usual workflow would be "pg_upgrade --check && pg_upgrade".  In which case the
> logs would end up being removed anyway.

Exactly, the inconsistency in the log handling is annoying, and
cleaning up the logs when --retain is not used makes sense to me when
the --check command succeeds, but we should keep them if the --check
fails.  I don't see an argument in backpatching that either.

> Hmm .. maybe what you mean is that the *tap test* should first run with
> --check?

Sorry for the confusion.  I meant to add an extra command in the TAP
test itself.

I would suggest the attached patch then, to add a --check command in
the test suite, with a change to clean up the logs when --check is
used without --retain.
--
Michael