On Mon, Jul 1, 2013 at 10:11:23AM -0400, Peter Eisentraut wrote:
> On 6/28/13 10:50 PM, Bruce Momjian wrote:
> > On Mon, Jan 28, 2013 at 09:46:32AM -0500, Peter Eisentraut wrote:
> >> On 1/26/13 4:44 PM, Aaron W. Swenson wrote:
> >>> You are right. Had I read a little further down, it seems that the
> >>> exit status should actually be 7.
> >>
> >> 7 is OK for "not running", but what should we use when the server is not
> >> in standby mode? Using the idempotent argument that we are discussing
> >> for the stop action, promoting a server that is not a standby should be
> >> a noop and exit successfully. Not sure if that is what we want, though.
> >
> > I looked at all the LSB return codes listed here and mapped them to
> > pg_ctl error situations:
> >
> >
> > https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
> >
> > Patch attached. I did not touch the start/stop return codes.
>
> Approximately none of these changes seem correct to me. For example,
> why is failing to open the PID file 6, or failing to start the server 7?
Well, according to that URL, we have:
6 program is not configured
7 program is not running
I just updated the pg_ctl.c comments to at least point to a valid URL
for this. I think we can just call this item closed because I am still
unclear if these return codes should be returned by pg_ctl or the
start/stop script.
Anyway, while I do think pg_ctl could pass a little more information
back about failure via its return code, I am unclear if LSB is the right
approach.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
