From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Skip checkpoint on promoting from streaming replication |
Date: | 2013-01-24 16:24:28 |
Message-ID: | CA+U5nMK8gjvWsJo9EvirYvpBa12x7DfW+9xO5T4FuFS1QSLM-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 January 2013 21:58, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 9 August 2012 10:45, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 22 June 2012 05:03, Kyotaro HORIGUCHI
>> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>
>>> I hope this is promising.
>>
>> I've reviewed this and thought about it over some time.
>
> I've been torn between the need to remove the checkpoint for speed and
> being worried about the implications of doing so.
>
> We promote in multiple use cases. When we end a PITR, or are
> performing a switchover, it doesn't really matter how long the
> shutdown checkpoint takes, so I'm inclined to leave it there in those
> cases. For failover, we need fast promotion.
>
> So my thinking is to make pg_ctl promote -m fast
> be the way to initiate a fast failover that skips the shutdown checkpoint.
>
> That way all existing applications work the same as before, while new
> users that explicitly choose to do so will gain from the new option.
Here's a patch to skip checkpoint when we do
pg_ctl promote -m fast
We keep the end of recovery checkpoint in all other cases.
The only thing left from Kyotaro's patch is a single line of code -
the call to ReadCheckpointRecord() that checks to see if the WAL
records for the last two restartpoints is on disk, which was an
important line of code.
Patch implements a new record type XLOG_END_OF_RECOVERY that behaves
on replay like a shutdown checkpoint record. I put this back in from
my patch because I believe its important that we have a clear place
where the WAL history changes timelineId. WAL format change bump
required.
So far this is only barely tested, but considering time goes on, I
thought people might want to pass comment on this.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
fast_promote.v3.patch | application/octet-stream | 13.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-01-24 16:27:32 | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Previous Message | Tom Lane | 2013-01-24 16:22:52 | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |