Thread: PID files Feature

Hey Richard,

You might want to give some of your suggestions to the actual PostgreSQL
folks (as opposed to this list, which focuses on PostgreSQL running
under Cygwin), possibly posting on the main PostgreSQL mailing lists.  I
know they have plans to release a true Windows native port of PostgreSQL
at some point, and not sure how they plan to handle this (though likely
they'll simply remove the whole PID concept, as in Windows with NT
services this becomes a moot point).  My understanding was that
originally v7.4 was to go native, but that was pushed back to at least
v7.5 at this point.

Anyway, just to clarify, I only explained the PID concept as we are
still dealing with (and sorry if this sounds blunt, but it's basically
the truth) a cludge.  Cygwin is an environment that allows Windows users
"a taste" of the Unix world...Linux if you want to be more specific, as
you might notice that Red Hat is the one who maintains Cygwin.

Having said that, the software everyone on this list is dealing
with--the Cygwin version of PostgreSQL--is NOT Windows software.  It's
Unix software.  [The fact you are running a form of Unix on top of
Windows is irrelevant.  The key is that the software itself is running
within the context of a Unix-type OS.]  Unix software follows Unix
software conventions.  Windows software follows Windows conventions.
Cygwin has some utilities/functionality such as cygrunsrv that allows
you to run a piece of Unix software kinda/sorta like a Windows service,
for example, but this is all cludge.  In truth, it is best to see Cygwin
apps as being Unix apps, and treat them as such.

As long as we are discussing the CYGWIN version of PostgreSQL, your
suggestions and ones like it are interesting, but honestly, they should
be directed at the PostgreSQL developers themselves in relation to the
Windows native port (which will not require cygwin1.dll if it's truly a
native app).  Someone may add a 3rd party utility/feature to implement
such suggestions under Cygwin, but they really have no relevance in the
Unix world, so adding them into PostgreSQL itself (under Cygwin) doesn't
really make sense.  And if you use Cygwin to run any app, be it
PostgreSQL, bash, gcc, or as in my case, Jabberd, you really should
think of it as BEING in Unix.  It will save you a great deal of headaches.

Yes, you can use cygrunsrv, for example, as I did, to turn a Cygwin app
into an NT service.  But it's not something that can be easily made a
standard part of Cygwin.  That is, when you install Cygwin packages,
they simply drop files into place.  Some things, like the
post-processing scripts of Cygwin's setup program, can possibly add
things like running cygrunsrv, but it's messy at best.  Truth is, only
those who understand what they're doing should try to hook things like
this together.

Cygwin isn't meant to be an OS on its own.  It's meant to allow Windows
users who NEED to run Windows to also have access to at least some of
the great *nix software out there.  In truth, in true production
environments, if you need to run PostgreSQL (at this point) or other
apps like it that are *nix-only, you really should build/run them on a
*nix platform proper, such as Linux, BSD, Solaris...heck, even Mac OS X.
  But Cygwin is not really intended to industrial-strength usage.  It's
more like a test platform...a way to get folks to see the power of *nix.
  Or for those poor *nix-loving bastards who see themselves stuck in a
Windows world, Cygwin offers them a taste of home while exiled in the
land of MS.

Anyway, just my $0.02 worth (you get a lot of words from me for $0.02 ;-) )


Richard Sydney-Smith wrote:
> Read the message by Frank outlining the reasons PID files are left to
> "protect" the user. Unfortunately this protection presumes a level of
> competance in the user that is not present in many MS Windows users. The
> point-and-click fraternity will consider the program "broken" if it
> fails to start.
>
> As a partial solution perhaps the postmaster can  raise a dialog,
> perhaps in a separate process, if a PID file exists? Two different
> options: Postmaster checks "process identification number" to see if it
> refers to a live process and then (1) If live tell the operator two
> postmasters can not run on the same computer or (2) indicate that the
> postmaster was not correctly shut down , data errors may exist and to
> run ...
>
> Such a response indicates clearly to the user that they were at fault,
> the program is not broken and if they want to run postgreSQL trouble
> free they should shut the computer down in an orderly fashion.
>
> Not all users have access to a tech-savy resource person and postgreSQL
> is such an excellent piece of software if would be a shame if people
> were put off using it simply because the program "does the right thing".
>
> In my own case I have built tests/messages in the application software
> that achieves a simular result and I am comfortable that ensuring
> postmaster runs on demand is nolonger an issue for my users or myself as
> a first call for support.
>
> best regards
>
> Richard Sydney-Smith
>