On Wed, 2009-09-30 at 11:58 -0500, Kevin Grittner wrote:
> Right. It seems that, in addition to the above, there also remains
> some disagreement about:
>
> (1) how much checking the script should do to provide error messages
> and exit codes which target the specific problems versus generic "I
Robert Haas wrote:
> Peter Eisentraut wrote:
>> On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
>>> It seems like there is some support for what this patch is trying
>>> to do, but much disagreement about the details of how to get
>>> there. Where do we go from here?
>>
>> I think the nex
On Mon, Sep 21, 2009 at 3:20 AM, Peter Eisentraut wrote:
> On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
>> It seems like there is some support for what this patch is trying to
>> do, but much disagreement about the details of how to get there.
>> Where do we go from here?
>
> I think the
On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
> It seems like there is some support for what this patch is trying to
> do, but much disagreement about the details of how to get there.
> Where do we go from here?
I think the next step would be to outline what changes would be
necessary in p
On Thu, Sep 17, 2009 at 4:52 PM, Robert Haas wrote:
> On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut wrote:
>> On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
>>> > Well, in such cases it may be useful to add an option such as
>>> > --oknodo to select the idempotent behavior.
>>>
>>>
On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut wrote:
> On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
>> > Well, in such cases it may be useful to add an option such as
>> > --oknodo to select the idempotent behavior.
>>
>> I found that confusing (as did Robert); how about --lsm-conf
On tor, 2009-09-17 at 14:21 -0400, Greg Smith wrote:
> I've implemented exactly the same logic Kevin describes for a past
> consulting customer and for multiple forms of shutdown scripts at
> Truviso.
> I would suggest the situation here is that it's so easy to script a
> custom
> solution that
On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
> > Well, in such cases it may be useful to add an option such as
> > --oknodo to select the idempotent behavior.
>
> I found that confusing (as did Robert); how about --lsm-conforming?
s/lsm/lsb/
I'm not so sure that I would label it as
On tor, 2009-09-17 at 09:26 -0400, Robert Haas wrote:
> On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut wrote:
> > Well, in such cases it may be useful to add an option such as --oknodo
> > to select the idempotent behavior.
>
> It took me about 60 seconds to figure out what I thought you were
On Thu, 17 Sep 2009, Peter Eisentraut wrote:
On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote:
Well, with differences in behavior, of course, like attempting a fast
shutdown, and escalating to an immediate shutdown if that doesn't
succeed in the allowed time.
Right, but if you think th
Peter Eisentraut wrote:
> I think it's important to consider what the "conforming behavior"
> really achieves in practice. The INFO section is essential nowadays
> for correct functioning on a large portion of distributions. The
> exit codes are relatively uninteresting but occasionally useful
On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut wrote:
> Well, in such cases it may be useful to add an option such as --oknodo
> to select the idempotent behavior.
It took me about 60 seconds to figure out what I thought you were
going for there, so I submit that's not a good choice of option
On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote:
> > what LSB actually entails, which is:
> >
> > - INFO header
> > - standardized exit codes
> > - functions from /lib/lsb/init-functions
>
> As well as a standardized set of actions and standard semantics for
> them, if we're only talking
Peter Eisentraut wrote:
> OK, I have a number of comments on this proposal.
Thanks for looking at it.
> What does it buy us, in general, and compared to the existing
> (non-LSB) script?
A conforming script for use in LSB conforming implementations.
> what LSB actually entails, which is:
OK, I have a number of comments on this proposal.
What does it buy us, in general, and compared to the existing (non-LSB)
script?
This becomes clearer when you consider what LSB actually entails, which
is:
- INFO header
- standardized exit codes
- functions from /lib/lsb/init-functions
My argum
Peter Eisentraut wrote:
> The commitfest lists this as the last patch, but there was some
> discussion after this. Could you/we clarify what is actually
> proposed for inclusion now? I have seen proposals for:
>
> - Linux LSB init script
> - Linux non-LSB init script
> - SUSE specific init sc
On Wed, 2009-09-02 at 15:06 -0500, Kevin Grittner wrote:
> Wolfgang Wilhelm wrote:
>
> > if [ $# -lt 1 -o "$1" = "" ] ] ; then
>
> Oops. Fixed patch attached. Thanks!
The commitfest lists this as the last patch, but there was some
discussion after this. Could you/we clarify what is actua
Wolfgang Wilhelm wrote:
> if [ $# -lt 1 -o "$1" = "" ] ] ; then
Oops. Fixed patch attached. Thanks!
-Kevin
Index: contrib/start-scripts/linux-lsb
===
RCS file: contrib/start-scripts/linux-lsb
diff -N contrib/start-scripts/li
etter ; Greg Stark ;
pgsql-hackers@postgresql.org
Gesendet: Montag, den 31. August 2009, 21:06:22 Uhr
Betreff: Re: [HACKERS] Linux LSB init script
Andrew Dunstan wrote:
> cvsutils
That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the
attached. This contains a
On ons, 2009-09-02 at 09:13 -0500, Kevin Grittner wrote:
> We don't have the distribution's PostgreSQL package installed on
> any of our machines, so I'd have to install it and risk breaking
> something to even have a look at it.
Using Midnight Commander is the canonical way to peek inside uninsta
Andrew Dunstan writes:
> Kevin Grittner wrote:
>> So while OpenSuse seems a little less restrictive, it's still not
>> something we can copy into the PostgreSQL distribution, right?
> right.
Right. Your clean-room approach seems to have been the right thing.
regards, to
On Wed, 2009-09-02 at 10:21 -0400, Andrew Dunstan wrote:
>
> Umm, no, you could either install the SRPM in a build directory, and
> look there, or extract the script from the built RPM using rpm2cpio.
... actually I am maintaining SuSE spec and patches unofficially in RPM
repository:
https://pr
Kevin Grittner wrote:
Andrew Dunstan wrote:
Kevin Grittner wrote:
[SuSE Linux Enterprise Server license]
Novell reserves all rights not expressly granted to You. You may
not:
(2) transfer the Software or Your license rights under this
Agreement, in whole or in part.
Andrew Dunstan wrote:
> Kevin Grittner wrote:
>> [SuSE Linux Enterprise Server license]
>> Novell reserves all rights not expressly granted to You. You may
>> not:
>> (2) transfer the Software or Your license rights under this
>> Agreement, in whole or in part.
> here is what's in what I got
Kevin Grittner wrote:
I tracked down the license text. It includes these sections, which
leave me disinclined to copy the init script to the PostgreSQL contrib
directory:
The Software is a collective work of Novell.
You must acquire a license for each
installation of the Software and for
Greg Stark wrote:
> Kevin Grittner wrote:
>> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
>> # All rights reserved.
>>
>> and that I would be violating that copyright by copying it to
>> PostgreSQL. Am I wrong?
>
> The above is just a statement of fact. It doesn't change th
On Wed, Sep 2, 2009 at 3:13 PM, Kevin
Grittner wrote:
> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
> # All rights reserved.
>
> and that I would be violating that copyright by copying it to
> PostgreSQL. Am I wrong?
The above is just a statement of fact. It doesn't change
Kevin Grittner wrote:
(2) We don't have the distribution's PostgreSQL package installed on
any of our machines, so I'd have to install it and risk breaking
something to even have a look at it.
Umm, no, you could either install the SRPM in a build directory, and
look there, or extrac
Peter Eisentraut wrote:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
>> 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 so
Kevin Grittner wrote:
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.
I recently build 8.4 RPMs for SL
On Sep 1, 2009, at 6:43 PM, Tom Lane wrote:
Debatable, but it's not upstream default, so why should it be
downstream
default?
FWIW, that particular issue is invariably a matter of distro policy;
they could care less what upstream's default is.
Well, they could, but do they?
/me offers Tom
Peter Eisentraut writes:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
>> 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
>> perf
On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
> 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.
Peter Eisentraut 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 SLES
On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote:
> My counter-argument to that would be that 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. So we switched
> to build from source before
On mån, 2009-08-31 at 20:54 -0400, Greg Smith wrote:
> On Mon, 31 Aug 2009, Kevin Grittner wrote:
>
> > My counter-argument to that would be that the SuSE distribution's
> > version of PostgreSQL is so out-of-date that we don't install it.
>
> Given that it's also RPM based, is it possible to get
On Mon, 31 Aug 2009, Kevin Grittner wrote:
My counter-argument to that would be that the SuSE distribution's
version of PostgreSQL is so out-of-date that we don't install it.
Given that it's also RPM based, is it possible to get SuSE in sync so that
it shares the same init script as RHEL? De
Peter Eisentraut wrote:
> While the major distributions support LSB, the major distributions
> also have PostgreSQL packages available and so will likely not need
> the init script shipped in the source.
My counter-argument to that would be that the SuSE distribution's
version of PostgreSQL is
On mån, 2009-08-31 at 12:07 -0500, Kevin Grittner wrote:
> Is the LSB standard sufficiently widely adopted to omit the older
> format? I was concerned that there might be Linux versions we wanted
> to support which wouldn't have a /lib/lsb/init-functions file to
> source. If that's not an issue,
Greg Smith wrote:
> I'm similarly not sure just what the benefits of a LSB compatible
> script are here given that several major distributions like
> RHEL/Debian have their own thing they're doing and are unlikely to
> change.
I don't know about other platforms, but on SuSE Linux, you're not
On Mon, 31 Aug 2009, Kevin Grittner wrote:
Is the LSB standard sufficiently widely adopted to omit the older
format?
I'm not sure, and I'm similarly not sure just what the benefits of a LSB
compatible script are here given that several major distributions like
RHEL/Debian have their own thin
Andrew Dunstan wrote:
> cvsutils
That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the
attached. This contains a couple minor fixes to what I posted in "new
file" form. I was holding off on the CommitFest entry until I sorted
out the format; I'll link here as version 1 of the
Peter Eisentraut wrote:
> If it's a new file, it's pointless to send a patch anyway.
If people are OK with just sending the new file, that's cool with me.
>From the other posts, it appears that I need to have my own copy of
the repository to do it as a patch, or download a tool. (Thanks to
t
David Fetter wrote:
On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote:
On Fri, Aug 28, 2009 at 10:57 PM, Kevin
Grittner wrote:
David Fetter wrote:
cvs diff if you're on CVS. If you're using git, commit to your
local repository and git-diff.
I tried that.
On Fri, Aug 28, 2009 at 11:59 PM, David Fetter wrote:
>> You have to "cvs add" the file
>
> That only works if you have write permissions to the central repo. I
> don't.
True. The only workable way to use cvs that i found was to rsync the
repository and then check out from that. If you cvs add th
On fre, 2009-08-28 at 16:57 -0500, Kevin Grittner wrote:
> David Fetter wrote:
>
> > cvs diff if you're on CVS. If you're using git, commit to your
> > local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the new
> file. When I specified the file
On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote:
> On Fri, Aug 28, 2009 at 10:57 PM, Kevin
> Grittner wrote:
> > David Fetter wrote:
> >
> >> cvs diff if you're on CVS. If you're using git, commit to your
> >> local repository and git-diff.
> >
> > I tried that. When I just did it at
On Fri, Aug 28, 2009 at 10:57 PM, Kevin
Grittner wrote:
> David Fetter wrote:
>
>> cvs diff if you're on CVS. If you're using git, commit to your
>> local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the new
> file. When I specified the file:
You h
On Fri, Aug 28, 2009 at 04:57:24PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
>
> > cvs diff if you're on CVS. If you're using git, commit to your
> > local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the
> new file. When I specified t
David Fetter wrote:
> cvs diff if you're on CVS. If you're using git, commit to your
> local repository and git-diff.
I tried that. When I just did it at the top level, it ignored the new
file. When I specified the file:
kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N
contrib/start-sc
On Fri, Aug 28, 2009 at 04:41:47PM -0500, Kevin Grittner wrote:
> I wrote:
>
> > But before I spend a lot of time fine-tuning it, I wanted to post
> > this as a proof-of-concept draft and see if people think it's on
> > the right track.
>
> I chose to take the lack of response as an indication
I wrote:
> But before I spend a lot of time fine-tuning it, I wanted to post
> this as a proof-of-concept draft and see if people think it's on the
> right track.
I chose to take the lack of response as an indication that nobody who
cares about this thought there was anything seriously wrong w
Here's a first rough cut of Linux script which attempts to launch
PostgreSQL as a somewhat LSB conforming application. It's very
lightly tested and I haven't gone through to confirm that every corner
case is handled exactly right; in fact on my kubuntu workstation (the
only place I've tested so fa
53 matches
Mail list logo
