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

On Sat, Jun 04, 2022 at 12:13:19PM +0900, Michael Paquier wrote:
> On Fri, Jun 03, 2022 at 06:55:28PM +0200, Daniel Gustafsson wrote:
> > On 3 Jun 2022, at 18:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> How about inserting an additional level of subdirectory?
> >> 
> >> pg_upgrade_output.d/20220603122528/foo.log
> >> 
> >> Then code doing "rm -rf pg_upgrade_output.d" needs no changes.
> > 
> > Off the cuff that seems like a good compromise.  Adding Andrew on CC: for input
> > on how that affects the buildfarm.
> 
> 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.

> 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.

On Sat, Jun 04, 2022 at 12:13:19PM +0900, Michael Paquier wrote:
> Seeing the top of the thread, I think that it would be a good idea to
> add an extra pg_upgrade --check before the real upgrade run.  I've
> also relied on --check as a safety measure in the past for automated
> workflows.

It already does this; --check really means "stop-after-checking".

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

-- 
Justin