Re: BUG #16081: pg_upgrade is failed if a fake cmd.exe exist in the current directory.

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

In response to

Browse pgsql-bugs by date

  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