Re: pg_ctl porting - Mailing list pgsql-hackers-win32

From Magnus Hagander
Subject Re: pg_ctl porting
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE171641@algol.sollentuna.se
Whole thread Raw
In response to pg_ctl porting  (Ronald Kuczek <kuczek@kuczek.pl>)
List pgsql-hackers-win32
>Hi all,
>
>I have skeleton from Claudio and  Keith Woodell.
>Idea to start postmaster as new console thread is - IMO all except
>productive solution.
>Postgres is running as service - quasi-service (the same thing you can
>realize with M$ srvany).
>My suggestion is - to add to postmaster Win32 service features.
>Start,stop,pause, restart, eventlog,service manager etc.
>For debugging purposes - developer can start postmaster in
>console like
>any application.
>If you want I can continue Claudio's work and complete pg_ctl, my
>opinion you know.
>Reload can be handled on Pause/ResumeService.
>Please tell me your choice, I'll realize it.


Hi!

First of all, there is a major difference between Keiths service code
and that of MS srvany: Keiths code supports a clean shutdown! (using our
"homemade signaling code") The MS code just kills the process.

Second, eventlog support is already in cvs.

This said, here are my thoughts:
If it can be integrated directly into the postmaster without there being
too big modifications to the postmaster (added stuff in port/win32 is
fine by me, but if it requires a lot of changes in the main code path,
not as fine), then that is a nicer way to do it. I don't think this
would be a problem, but I haven't looked at it specifically. And as you
said, it still has to be possible to run it on the console - accepting
standard parameters, nothing special required.


Considering we CreateProcess on every backend call, having a separate
binary running as "postmaster service manager" is not that bad if we
need it, though.


And I like the idea about translating Pause into reload. I've seen this
done with many other win32 services, so we're not inventing something
unintuitive there.


//Magnus

pgsql-hackers-win32 by date:

Previous
From: Ronald Kuczek
Date:
Subject: pg_ctl porting
Next
From: Claudio Natoli
Date:
Subject: Re: pg_ctl porting