Re: pg_ctl idempotent option - Mailing list pgsql-hackers

From Asif Naeem
Subject Re: pg_ctl idempotent option
Date
Msg-id CAEB4t-MX_m7XoiiObkxV2Ve+XSS+Erm-3GKN7jqBo0t80_z9pA@mail.gmail.com
Whole thread Raw
In response to pg_ctl idempotent option  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
I am working on reviewing the patch. Patch apply without warning/error on master branch. My findings are as following i.e.

1. Behavior change in pg_ctl return value i.e.

     Server already running
a. Without Patch

inst asif$ ./bin/pg_ctl -D data_test/ -l data_test.log start
pg_ctl: another server might be running; trying to start server anyway
server starting
inst asif$ echo $?
0

b. With Patch

inst_pg_ctl_idempotent_option asif$ ./bin/pg_ctl -D data_test/ -l data_test.log start
pg_ctl: another server might be running
inst_pg_ctl_idempotent_option asif$ echo $?
1

2. -w option seems not working for start as per documentation, it should return 0.

Starting already running server with -I -w option

inst_pg_ctl_idempotent_option asif$ ./bin/pg_ctl -D data_test/ -l data_test.log -I -w start
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start........
pg_ctl: this data directory appears to be running a pre-existing postmaster
 stopped waiting
pg_ctl: could not start server
Examine the log output.
inst_pg_ctl_idempotent_option asif$ echo $?
1

3. I believe postmaster (DAEMON="$prefix/bin/postmaster") is not going to accept "-I" option as mentioned in the patch i.e.

contrib/start-scripts/linux
     su - $PGUSER -c "$DAEMON -I -D '$PGDATA' &" >>$PGLOG 2>&

Rest of the patch changes looks good to me. Thanks.

Best Regards,
Asif Naeem

On Thu, Jan 24, 2013 at 6:06 PM, Bruce Momjian 
<bruce@momjian.us> wrote:
On Thu, Jan 24, 2013 at 09:05:59AM +0530, Ashutosh Bapat wrote:
> I agree, answering the question, whether the particular attempt of
> starting a server succeeded or not, will need the current behaviour.
> Now, question is which of these behaviours should be default?

That would work.  pg_upgrade knows the cluster version at that point and
can use the proper flag.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "pg_ctl promote" exit status
Next
From: Peter Eisentraut
Date:
Subject: Re: plpgsql_check_function - rebase for 9.3