Re: Skip checkpoint on promoting from streaming replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Skip checkpoint on promoting from streaming replication
Date
Msg-id CA+U5nMK8gjvWsJo9EvirYvpBa12x7DfW+9xO5T4FuFS1QSLM-w@mail.gmail.com
Whole thread Raw
In response to Re: Skip checkpoint on promoting from streaming replication  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Skip checkpoint on promoting from streaming replication
List pgsql-hackers
On 6 January 2013 21:58, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 9 August 2012 10:45, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 22 June 2012 05:03, Kyotaro HORIGUCHI
>> <horiguchi.kyotaro@lab.ntt.co.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Next
From: Andres Freund
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]