Re: CI/windows docker vs "am a service" autodetection on windows

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Subject: Re: CI/windows docker vs "am a service" autodetection on windows
Date: 2021-03-04 20:36:23
Message-ID: CABUevEx9FK3ZP+6Re-CKdVM1dDdi-N5UynkpcTs3z4M3JQJkGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 4, 2021 at 9:30 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2021-03-04 21:08:30 +0100, Magnus Hagander wrote:
> > The problem with doing it at register time is that everybody who
> > builds an installer for PostgreSQL will then have to do it in their
> > own registration (I'm pretty sure most of them don't use pg_ctl
> > register).
>
> Well, hm, maybe they should change that?
>
>
> > The same thing in pgwin32_doRunAsService() might help with that.
>
> What do you mean by this?

I mean controlling this flag by entry into pgwin32_doRunAsService().
So that when we start *postgres* we pass a parameter along saying that
it's a service and should use eventlog for the early exit.
pgwin32_doRunAsService() will (of course) only be called when started
with runservice. That would, I think, sort out the problem for the
postgres processes, and leave us with just pg_ctl to figure out.

> > But then we'd have to figure out what to do if pg_ctl fails prior to
> > reaching that point... There aren't that many such paths, but there
> > are some.
> >
> > Just throwing out ideas without spending time thinking about it, maybe
> > log to *both* in the case when we pick by it by autodetection?
>
> 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...

> There does seem to be isatty(), so we could improve the case of
> pg_ctl/postgres run interactively without breaking a sweat. And there is
> fstat() too, so if stderr in a service is something distinguishable...

We seem to have used that at some point, but commit
a967613911f7ef7b6387b9e8718f0ab8f0c4d9c8 got rid of it... But maybe
apply it in a combination.

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-03-04 20:39:49 Re: [POC] Fast COPY FROM command for the table with foreign partitions
Previous Message Andres Freund 2021-03-04 20:30:08 Re: CI/windows docker vs "am a service" autodetection on windows