From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch |
Date: | 2022-06-03 14:52:09 |
Message-ID: | 5A7C47A4-A791-459F-AAA4-83008D1E9D09@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 3 Jun 2022, at 15:53, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> On Fri, Jun 03, 2022 at 02:01:18PM +0200, Daniel Gustafsson wrote:
>>> On 3 Jun 2022, at 13:19, tushar <tushar(dot)ahuja(at)enterprisedb(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-06-03 15:12:11 | Re: Proposal: adding a better description in psql command about large objects |
Previous Message | Nathan Bossart | 2022-06-03 14:39:21 | Re: Proposal: adding a better description in psql command about large objects |