On Fri, Jun 03, 2022 at 02:01:18PM +0200, Daniel Gustafsson wrote: > > On 3 Jun 2022, at 13:19, tushar <tushar.ah...@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
