[Andres Freund <andres@anarazel.de>]

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