Re: BUG #16081: pg_upgrade is failed if a fake cmd.exe exist in thecurrent directory. - Mailing list pgsql-bugs

From Daniel Gustafsson
Subject Re: BUG #16081: pg_upgrade is failed if a fake cmd.exe exist in thecurrent directory.
Date
Msg-id 32420B2E-6537-473A-8AD6-D84BEF6AF722@yesql.se
Whole thread Raw
In response to BUG #16081: pg_upgrade is failed if a fake cmd.exe exist in the current directory.  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
> On 26 Oct 2019, at 06:32, PG Bug reporting form <noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference:      16081
> Logged by:          cili
> Email address:      cilizili@protonmail.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


pgsql-bugs by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: BUG #16016: deadlock with startup process, AccessExclusiveLockon pg_statistic's toast table
Next
From: Tom Lane
Date:
Subject: Re: BUG #16016: deadlock with startup process, AccessExclusiveLock on pg_statistic's toast table