From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | cilizili(at)protonmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16081: pg_upgrade is failed if a fake cmd.exe exist in the current directory. |
Date: | 2019-11-01 22:26:08 |
Message-ID: | 32420B2E-6537-473A-8AD6-D84BEF6AF722@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On 26 Oct 2019, at 06:32, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 16081
> Logged by: cili
> Email address: cilizili(at)protonmail(dot)com
> PostgreSQL version: 12.0
> Operating system: Microsoft Windows [Version 10.0.18362.418]
> Description:
>
> Similar to the case of pg_ctl. If a fake cmd.exe exits in current directory,
> pg_upgrade is failed to start.
>
> Instructions:
> # cd %TEMP%
> # "c:\Program Files\PostgreSQL\12\bin\pg_ctl.exe" initdb -D test
> # set PGDATAOLD=%TEMP%\test
> # set PGDATANEW=%TEMP%\test
> # set PGBINOLD=c:\Program Files\PostgreSQL\12\bin
> # set PGBINNEW=c:\Program Files\PostgreSQL\12\bin
> # copy %windir%\system32\calc.exe cmd.exe
> # "c:\Program Files\PostgreSQL\12\bin\pg_upgrade”
pg_upgrade aborting an upgrade in a broken environment seems like proper
behavior. Not knowing Windows I might be missing something, but when is this
ever a legitimate usecase?
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-02 15:10:06 | Re: BUG #16016: deadlock with startup process, AccessExclusiveLock on pg_statistic's toast table |
Previous Message | Dmitry Dolgov | 2019-11-01 15:56:30 | Re: BUG #16016: deadlock with startup process, AccessExclusiveLock on pg_statistic's toast table |