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.
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...
|$ time /usr/pgsql-15/bin/pg_upgrade -b /usr/pgsql-14/bin -d ./pgsql14.dat -D ./pgsql15.dat
|could not create directory "pgsql15.dat/pg_upgrade_output.d": File exists
|Failure, exiting
This is a kind of geometric circle of errors - an error at point A requires
first re-running after fixing A's issue, and then an error at B requires
re-running after fixing B's issue, hitting the "A" error again, and then
rerunning again again. It's the same kind of problem that led to 3c0471b5f.
-c could use a different output directory, but that means it would fail if
pg_upgrade -c were run multiple times, which seems undesirable for a "check"
command.
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.
--
Justin