Re: Linux LSB init script - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Linux LSB init script
Date
Msg-id 4A9D0DC2020000250002A782@gw.wicourts.gov
Whole thread Raw
In response to Re: Linux LSB init script  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Linux LSB init script
Re: Linux LSB init script
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> wrote: 
> On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote:
>> the SuSE distribution's version of PostgreSQL is so out-of-date
>> that we don't install it.  It also doesn't enable debug info or
>> integer date times.
> Fixes and help are welcome, btw.
We're using SLES10.  If we installed the latest from the SuSE site, we
would be at PostgreSQL version 8.1.  Now, to their credit, that is
8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
whether to go back to 8.1.
And unless I'm remembering incorrectly, the configure options are not
what we would want.  I don't see any reason the packaged build
shouldn't be with --enable-debug on a platform where that has no
performance hit.  I never understood why anyone converting to
PostgreSQL would want the floating point approximate timestamps rather
than using --enable-integer-datetimes.  We don't have a need for
multiple languages, so I figure it's best to use --diable-nls,
although I doubt that one's a huge deal.  Since we have much XML in
our database, I'm building with --with-libxml, just in case someone
decides they want to use xpath.  And since we often need more than one
version of PostgreSQL on a server, we always use a prefix of
/usr/local/pgsql-<version> and use a symlink to map one version to the
"default" we put on our PATH.  (Our init scripts always point to the
version-specific locations.)
I wouldn't expect a packaged SuSE build to cater to all of that; but
it would be nice if they donated their init script to the PostgreSQL
project, so that those of us who have a reason to build from source
on SuSE have have a convenient starting point in the source
distribution of PostgreSQL.
I seem to remember that SuSE has an abstraction layer similar to the
functions I defined in my linux-lsb script.  I couldn't use those in a
portable LSB submission, but if there's anything in what I did which
is of any use to SuSE, there's no reason for SuSE not to use it.  I'm
putting it under the same license as the rest of PostgreSQL. 
Although, now that I think of it, I don't think I actually put any
copyright or license message into the file yet.
In any event, I think I've come up with something which should work
pretty well on any LSB conforming implementation, including SuSE.  If
we get the pg_ping functionality which is occassionally discussed, it
can be made really bulletproof.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Move processing of startup-packet switches and GUC settings into
Next
From: Simon Riggs
Date:
Subject: Re: remove flatfiles.c