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