Re: Add shutdown_at_recovery_target option to recovery.conf - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Add shutdown_at_recovery_target option to recovery.conf
Date
Msg-id 546CB667.7040805@2ndquadrant.com
Whole thread Raw
In response to Re: Add shutdown_at_recovery_target option to recovery.conf  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 19/11/14 14:13, Simon Riggs wrote:
> On 18 November 2014 22:05, Petr Jelinek <petr@2ndquadrant.com> wrote:
>
>> OK, promote works for me as well, I attached patch that changes continue to
>> promote so you don't have to find and replace everything yourself. The
>> changed doc wording probably needs to be checked.
>
> I've reworded docs a little.
>
> Which led me to think about shutdown more.
>
> If we ask for PAUSE and we're not in HotStandby it just ignores it,
> which means it changes into PROMOTE. My feeling is that we should
> change that into a SHUTDOWN, not a PROMOTE. I can raise that
> separately if anyone objects.

Ok that seems reasonable, I can write updated patch which does that.

> Also, for the Shutdown itself, why are we not using
>     kill(PostmasterPid, SIGINT)?
>
> That gives a clean, fast shutdown rather than what looks like a crash.
>

My first (unsubmitted) version did that, there was some issue with 
latches when doing that, but I think that's no longer problem as the 
point at which the shutdown happens was moved away from the problematic 
part of code. Other than that, it's just child killing postmaster feels 
bit weird, but I don't have strong objection to it.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: Functions used in index definitions shouldn't be changed
Next
From: Robert Haas
Date:
Subject: Re: alternative model for handling locking in parallel groups