Re: pg_ctl non-idempotent behavior change - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_ctl non-idempotent behavior change
Date
Msg-id 20140804210747.GM5475@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pg_ctl non-idempotent behavior change  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_ctl non-idempotent behavior change
List pgsql-hackers
Tom Lane wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
> > After 87306184580c9c49717, if the postmaster dies without cleaning up (i.e.
> > power outage), running "pg_ctl start" just gives this message and then
> > exits:
> 
> > pg_ctl: another server might be running
> 
> > Under the old behavior, it would try to start the server anyway, and
> > succeed, then go through recovery and give you back a functional system.
> 
> > From reading the archive, I can't really tell if this change in behavior
> > was intentional.
> 
> Hmm.  I rather thought we had agreed not to change the default behavior,
> but the commit message fairly clearly says that the default behavior is
> being changed.  This case shows that that change was inadequately
> thought through.
> 
> > Anyway it seems like a bad thing to me.  Now the user has a system that
> > will not start up, and is given no clue that they need to remove
> > "postmaster.pid" and try again.
> 
> Yeah, this is not tolerable.  We could think about improving the logic
> to have a stronger check on whether the old server is really there or
> not (ie it should be doing something more like pg_ping and less like
> just checking if the pidfile is there).  But given how close we are to
> beta, maybe the best thing is to revert that change for now and put it
> back on the to-think-about-for-9.4 list.  Peter?

Are we going to unrevert this patch for 9.5?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: KNN-GiST with recheck
Next
From: John Cochran
Date:
Subject: Re: Looked at TODO:Considering improving performance of computing CHAR() value lengths