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

> On 3 Jun 2022, at 15:53, Justin Pryzby <pryzby@telsasoft.com> wrote:
> 
> On Fri, Jun 03, 2022 at 02:01:18PM +0200, Daniel Gustafsson wrote:
>>> On 3 Jun 2022, at 13:19, tushar <tushar.ahuja@enterprisedb.com> wrote:
>> 
>>> This behavior was not there in earlier released versions, i guess. 
>>> Is it expected behavior now onwards?
>> 
>> That's an unfortunate side effect which AFAICT was overlooked in the original
>> thread.  Having a predictable name was defined as important for CI/BF, but I
>> agree that the above is likely to be a common user pattern (first running -c is
>> exactly what I did when managing databases and upgraded them with pg_upgrade).
> 
> I agree that it's an problem, but it's not limited to -c.

Indeed.

> For example, I ran this:
> 
> |$ time /usr/pgsql-15/bin/pg_upgrade -b /usr/pgsql-14/bin/initdb -d ./pgsql14.dat -D ./pgsql15.dat 
> |"/usr/pgsql-14/bin/initdb" is not a directory
> |Failure, exiting
> 
> And then reran with the correct "-b" option, but then it failed because it had
> failed before...

Thats, not ideal.

> We could call cleanup() if -c was successful.  But that doesn't help the case
> that -c fails; the new dir would still need to be manually removed, which seems
> like imposing useless busywork on the user.
> 
> We could allow mkdir to fail with EEXIST, except that breaks the original
> motivation for the patch: the logs are appended to and any old errors are still
> in the logs after re-running pg_upgrade.

Or we could revisit Tom's proposal in the thread that implemented the feature:
to have timestamped directory names to get around this very problem?  I think
we should be able to figure out a way to make it easy enough for the BF code to
figure out (and clean up).

--
Daniel Gustafsson		https://vmware.com/