Re: PGSVC : PostgreSQL Windows Service Manager

>I found the Win32 Native status page and compiled PostgreSQL.
>Then I ported
>a few databases, which seem to work fine except for minor
>quirks. This got
>me so very happy!!

Great to hear!


>So ... I wrote a small service manager. It starts, stops and recovers
>postmaster -- even on shutdown and startup. I've tested in on
>WinXP. It also
>installs and uninstalls the service. I realize that this was
>on the "TODO"
>list, so I hope I didn't step on anyone's toes. Honestly, I
>was just going
>to horde this little app for myself, but ... in the name of
>open source!

This looks like a good start. However, for this to be included in the
main distribution, it cannot rely on Borland C++ builder - it has to
compile with mingw. Since there is no other C++ code in postgresql, just
plain C, I'd say try to stick to that if possible. (I don't see much
C++ism in there, so this should probably be easy)

Also, please note that GPL code is not compatible with the current
postgresql license - check the archives for multiple discussions on
including GPL code.


>Major missing component: I cannot redirect standard output/error on the
>postmaster "child process" in Windows ... I spent way too many
>hours with no
>results, and many different techniques. When I fix this, PGSVC will be
>feature complete. If there's no way to redirect stdout/stderr,
>then I'd like
>to suggest that Win32 code be added to the PGSQL CVS. The code
>should send
>stdout/stderr to a named pipe (just the way signals are rewritten for
>Win32). I would not recommend using the Windows Event Log,
>because I've seen
>PGSQL logs get to be several megs large when using a high
>debug level. That
>would be a real hassle to to use the crappy WinEventLog
>interface ... imho.

It should be quite possible to redirect these pipes using the data in
STARTUPINFO. I'm not sure how that will handle subprocesses executed
from the postmaster though, perhaps there is where your problem is?

As for using the eventlog - I think that depends a lot on the
environment. When debugging it's probably not the right thing (though I
would argue you could/should launch it from the commandline when you do
debugging).

But definitly, having both options would be good.

(Oh, and I quite like the eventlog interface. Especially how it
integrates with existing management and monitoring tools)



//Magnus