From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Asif Naeem <anaeem(dot)it(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add shutdown_at_recovery_target option to recovery.conf |
Date: | 2014-11-19 15:25:27 |
Message-ID: | 546CB667.7040805@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19/11/14 14:13, Simon Riggs wrote:
> On 18 November 2014 22:05, Petr Jelinek <petr(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-11-19 15:26:50 | Re: alternative model for handling locking in parallel groups |
Previous Message | Antonin Houska | 2014-11-19 15:21:29 | Re: Functions used in index definitions shouldn't be changed |