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. +
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. |