> On 3 Jun 2022, at 15:53, Justin Pryzby <pry...@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.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.
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/
