NT service design choices

I've been working on getting PostgreSQL to run as an NT service. So
far I've been adding code that builds into postgres.exe, and causes a
new top-level service-management postgres process to run that in turn
forks the normal 'postmaster' process. This split is necessary
because of certain Cygwin constraints on use of signals and multiple
threads.

But the 'cgyrunsrv' application has recently become available,
providing a general wrapper capability for running any Cygwin process
as as service. I'm strongly considering using this wrapper to run
PostgreSQL rather than continuing with the approach of integrating the
service-management code right into postgres itself.

So, the question I put to this community is:

* Do you care whether we implement the NT-service mode of
PostgreSQL via the cygrunsrv wrapper vs. integrated code?
If so, why?

The way I see it, the main trade-offs are these:

Integrated service-management code:
+ Easy to add management features important to PostgreSQL
(mostly done already).
- Makes postgres.exe larger.
-- Adds new source code to pgsql that must be maintained, much
of it specific to arcane NT-service management policies.
- Requires changes to main() function in postgres.exe.

Separate cygrunsrv wrapper:
++ Might be possible to wrap postgres with no code changes to
PostgreSQL at all. (However, probably still need to ignore
SIGHUP in postmaster and postgres backend processes).
- Need to implement features in cygrunsrv that are specific
to only the PostgreSQL case so far. (dependency on other
services, specific signals to shutdown the application,
logging all output to a file, clean shutdown in event of NT
shutdown).
+ Do not need to maintain the NT-service management code in
PostgreSQL.
- Requires PostgreSQL administrator to get and configure the
cygrunsrv application as well.

--
Fred Yankowski fred(at)OntoSys(dot)com tel: +1.630.879.1312
Principal Consultant www.OntoSys.com fax: +1.630.879.1370
OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA