Hi, On 2021-03-04 12:48:59 -0800, Andres Freund wrote: > On 2021-03-04 21:36:23 +0100, Magnus Hagander wrote: > > > I think that's a good answer for pg_ctl - not so sure about postgres > > > itself, at least once it's up and running. I don't know what lead to all > > > of this autodetection stuff, but is there the possibility of blocking on > > > whatever stderr is set too as a service? > > > > > > Perhaps we could make the service detection more reliable by checking > > > whether stderr is actually something useful? > > > > So IIRC, and mind that this is like 15 years ago, there is something > > that looks like stderr, but the contents are thrown away. It probably > > exists specifically so that programs won't crash when run as a > > service... > > Yea, that'd make sense. > > I wish we had tests for the service stuff, but that's from long before > there were tap tests...
After fighting with a windows VM for a bit (ugh), it turns out that yes, there is stderr, but that fileno(stderr) returns -2, and GetStdHandle(STD_ERROR_HANDLE) returns NULL (not INVALID_HANDLE_VALUE). The complexity however is that while that's true for pg_ctl within pgwin32_ServiceMain: checking what stderr=00007FF8687DFCB0 is (handle: 0, fileno=-2) but not for postmaster or backends WARNING: 01000: checking what stderr=00007FF880F5FCB0 is (handle: 92, fileno=2) which makes sense in a way, because we don't tell CreateProcessAsUser() that it should pass stdin/out/err down (which then seems to magically get access to the "topmost" console applications output - damn, this stuff is weird). You'd earlier mentioned that other distributions may not use pg_ctl register - but I assume they use pg_ctl runservice? Or do they actually re-implement all those magic incantations in pg_ctl.c? Greetings, Andres Freund
