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(at)sss(dot)pgh(dot)pa(dot)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