Re: pg_ctl status with nonexistent data directory

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
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-08 17:16:12
Message-ID: 20140308171612.GB4690@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 8, 2014 at 09:08:31AM +0530, Amit Kapila wrote:
> On Fri, Mar 7, 2014 at 7:59 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Fri, Mar 7, 2014 at 07:18:04PM +0530, Amit Kapila wrote:
> >> > 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.
> >
> > OK, I have updated the attached patch to reflect this, and added a C
> > comment.
>
> This is fine, do you think we should mention about this in docs?
> I have added one line in docs (updated patch attached), if you think
> it makes sense then add it otherwise ignore it.

I have applied your version of the patch with slightly different text:

If an accessible data directory is not specified, the process returns an
exit status of 4.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-03-08 17:20:44 Re: Comment - uniqueness of relfilenode
Previous Message Tom Lane 2014-03-08 17:12:21 Re: Little confusing things about client_min_messages.