Re: pg_ctl status with nonexistent data directory - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_ctl status with nonexistent data directory
Date
Msg-id CAA4eK1JwDU0xDOcWW4Gy-x85pvVeX7YDWgr58-TfSkAXKj_hDA@mail.gmail.com
Whole thread Raw
In response to Re: pg_ctl status with nonexistent data directory  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_ctl status with nonexistent data directory  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Mar 7, 2014 at 9:41 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, Mar  7, 2014 at 09:07:24AM +0530, Amit Kapila wrote:
>> One reason could be that as we are already returning special exit code
>> for 'status' option of pg_ctl (exit(3)), this seems to be inline with it as this
>> also get called during status command.
>>
>> Also in the link sent by you in another mail, I could see some statement
>> which indicates it is more important to return correct codes in case of
>> status which sounds a good reason to me.
>>
>> Link and statement
>> http://www.postgresql.org/message-id/51D1E482.5090602@gmx.net
>>
>> "The "status" case is different, because there the exit code
>> can be passed out by the init script directly."
>>
>> If we just want to handle correct exit codes for "status" option, then
>> may be we need to refactor the code a bit to ensure the same.
>
> OK, done with the attached patch  Three is returned for status, but one
> for other cases.

I think it would have been better if it return status as 4 for cases where
directory/file is not accessible (current new cases added by this patch).

I think status 3 should be only return only when the data directory is valid
and pid file is missing, because in script after getting this code, the next
thing they will probably do is to start the server which doesn't seem a
good fit for newly added cases.

Other than that patch seems fine to me.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Row-security on updatable s.b. views
Next
From: Robert Haas
Date:
Subject: Re: GSoC on WAL-logging hash indexes