Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows

On Thu, Jun 06, 2024 at 05:21:46PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 06 Jun 2024 17:15:15 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> > By the way, the need to shift by 2 seconds to tolerate clock skew
> > suggests that the current launcher-postmaster association mechanism is
> > somewhat unreliable. Couldn't we add a command line option to
> > postmaster to explicitly pass a unique identifier (say, pid itself) of
> > the launcher? If it is not specified, the number should be the PID of
> > the immediate parent process.
>
> No. The combination of pg_ctl's pid and timestamp, to avoid false
> matching during reboot.
>
> > This change avoids the need for the special treatment for Windows.

Regarding your "unique identifier" idea, pg_ctl could generate an 8-byte
random value for the postmaster to write to postmaster.pid. That would be
enough for wait_for_postmaster_start() to ignore PIDs and achieve its mission
without OS-specific code.

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?