Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Date
Msg-id YprNz9SGIiRN7pvB@paquier.xyz
Whole thread Raw
In response to Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
List pgsql-hackers
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, 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.

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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade test writes to source directory