Re: pg_ctl status with nonexistent data directory

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_ctl status with nonexistent data directory
Date: 2014-03-07 13:48:04
Message-ID: CAA4eK1JwDU0xDOcWW4Gy-x85pvVeX7YDWgr58-TfSkAXKj_hDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 7, 2014 at 9:41 AM, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-03-07 13:48:45 Re: GSoC on WAL-logging hash indexes
Previous Message Craig Ringer 2014-03-07 13:33:40 Re: Row-security on updatable s.b. views