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