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.ntt@gmail.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?