Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows
Date
Msg-id ZoeCemTDhF0OxuB2@paquier.xyz
Whole thread Raw
In response to Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows  (Noah Misch <noah@leadboat.com>)
Responses Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows
List pgsql-hackers
On Sat, Jun 29, 2024 at 07:12:11PM -0700, Noah Misch wrote:
> Commits 9886744 and b83747a added /D to two %comspec% callers.  I gather they
> arose to make particular cmd.exe invocations have just one child.  However,
> http://postgr.es/m/20240111.173322.1809044112677090191.horikyota.ntt@gmail.com
> reports multiple children remain possible.  v17 is currently in a weird state
> where most Windows subprocess invocation routes through pgwin32_system() and
> does not add /D, while these two callers add /D.  I suspect we should either
> (1) prepend /D in pgwin32_system() and other %comspec% usage or (2) revert
> prepending it in the callers from this thread's commits.  While
> "Software\Microsoft\Command Processor\AutoRun" is hard to use without breaking
> things, it's not PostgreSQL's job to second-guess the user in that respect.
> Hence, I lean toward (2).  What do you think?

Thanks for the ping.

As of this stage of the game for v17, I am going to agree with (2) to
remove this inconsistency rather than experiment with new things.  We
could always study more in v18 what could be done with the /D switches
and the other patch, though that will unlikely be something I'll be
able to look at in the short term.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Use generation memory context for tuplestore.c
Next
From: Michael Paquier
Date:
Subject: Re: Test to dump and restore objects left behind by regression