From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch |
Date: | 2022-06-04 03:32:27 |
Message-ID: | 20220604033227.GP29853@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-06-04 03:35:45 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |
Previous Message | Michael Paquier | 2022-06-04 03:21:42 | Re: pg_upgrade test writes to source directory |