Hi, I'm reviewing patches in Commitfest 2024-07 from top to bottom: https://commitfest.postgresql.org/48/
This is the 2st patch: https://commitfest.postgresql.org/48/4573/ FYI: https://commitfest.postgresql.org/48/4681/ is my patch. In <zl5sc_kboy7i0...@paquier.xyz> "Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows" on Tue, 4 Jun 2024 08:30:19 +0900, Michael Paquier <mich...@paquier.xyz> wrote: > During a live review of this patch last week, as part of the Advanced > Patch Workshop of pgconf.dev, it has been mentioned by Tom that we may > be able to simplify the check on pmstart if the detection of the > postmaster PID started by pg_ctl is more stable using the WIN32 > internals that this patch relies on. I am not sure that this > suggestion is right, though, because we should still care about the > clock skew case as written in the surrounding comments? Even if > that's OK, I would assume that this should be an independent patch, > written on top of the proposed v6-0001. I reviewed the latest patch set and I felt different impression. start_postmaster() on Windows uses cmd.exe for redirection based on the comment in the function: > /* > * As with the Unix case, it's easiest to use the shell (CMD.EXE) to > * handle redirection etc. Unfortunately CMD.EXE lacks any equivalent of > * "exec", so we don't get to find out the postmaster's PID immediately. > */ It seems that we can use redirection by CreateProcess() family functions without cmd.exe based on the following documentation: https://learn.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output How about changing start_postmaster() for Windows to start postgres.exe directly so that it returns the postgres.exe's PID not cmd.exe's PID? If we can do it, we don't need pgwin32_find_postmaster_pid() in the patch set. Thanks, -- kou