Thread

  1. Re: "pg_ctl promote" exit status

    Dhruv Ahuja <dhruvahuja@gmail.com> — 2013-01-25T18:36:49Z

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