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

From Tom Lane
Subject Re: pg_ctl non-idempotent behavior change
Date
Msg-id 437.1367087057@sss.pgh.pa.us
Whole thread Raw
In response to pg_ctl non-idempotent behavior change  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: pg_ctl non-idempotent behavior change
Re: pg_ctl non-idempotent behavior change
List pgsql-hackers
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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Remaining beta blockers
Next
From: Robert Haas
Date:
Subject: Re: exactly what is COPY BOTH mode supposed to do in case of an error?