Re: "pg_ctl promote" exit status - Mailing list pgsql-hackers

From Dhruv Ahuja
Subject Re: "pg_ctl promote" exit status
Date
Msg-id CANv0W22zdexMQyMMvnqEqEoy1wVZA3QCaX01dbzZnoL06vbLmA@mail.gmail.com
Whole thread Raw
In response to "pg_ctl promote" exit status  (Dhruv Ahuja <dhruvahuja@gmail.com>)
List pgsql-hackers
Don't think the attachment made it in the last mail. Attaching now.


On 25 January 2013 18:33, Dhruv Ahuja <dhruvahuja@gmail.com> wrote:
May I propose the attached patch.

Points to note and possibly discuss:
(a) Only exit codes in do_* functions have been changed.
(b) The link to, and the version of, LSB specifications has been updated.
(c) A significant change is the exit code of do_stop() on stopping a stopped server. Previous return is 1. Proposed return is 0. If this is accepted, I would highly suggest a mention in the Release Notes.
(d) The exit code that raised this issue was the return of promoting a promoted server. If promotion fails because the server is running but not as standby, should that be considered a case of starting a started service, or an application specific failure? I am equally weighted to opt for the former, but have proposed differently in the patch.



On 23 October 2012 17:29, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Oct 23, 2012 at 6:39 AM, Dhruv Ahuja <dhruvahuja@gmail.com> wrote:
> The "pg_ctl promote" command returns an exit code of 1 when the server
> is not in standby mode, and the same exit code of 1 when the server
> isn't started at all. The only difference at the time being is the
> string output at the time, which FYI are...
>
> pg_ctl: cannot promote server; server is not in standby mode
>
> ...and...
>
> pg_ctl: PID file "/var/lib/pgsql/9.1/data/postmaster.pid" does not exist
> Is server running?
>
> ...respectively.
>
> I am in the process of developing a clustering solution around luci
> and rgmanager (in Red Hat EL 6) and for the time being, am basing it
> off the string output. Maybe each different exit reason should have a
> unique exit code, whatever my logic and approach to solving this
> problem be?

That doesn't seem like a bad idea.  Got a patch?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Doc patch, normalize search_path in index
Next
From: Bruce Momjian
Date:
Subject: Re: Doc patch, normalize search_path in index