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

On 12 June 2012 03:38, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> Hello, sorry for vague understanding.
>
>> > I depend on this and suppose we can omit it if latest checkpoint
>> > has been taken so as to be able to do crash recovery thereafter.
>>
>> I don't see any reason to special case this. If a checkpoint has no
>> work to do, then it will go very quickly. Why seek to speed it up even
>> further?
>
> I want the standby to start to serve as soon as possible even by
> a few seconds on failover in a HA cluster.

Please implement a prototype and measure how many seconds we are discussing.


>> > This condition could be secured by my another patch for
>> > checkpoint_segments on standby.
>>
>> More frequent checkpoints are very unlikely to secure a condition that
>> no checkpoint at all is required at failover.
>
> I understand that checkpoint at the end of recovery is
> indispensable to ensure the availability of crash recovery
> afterward. Putting aside the convention about TLI increment and
> shutdown checkpoint, shutdown checkpoints there seems for me to
> be omittable if (and not 'only if', I suppose) crash recovery is
> available at the time.
>
> Shutdown checkpoint itself seems dispansable to me, but I'm
> shamingly not convinced so taking the TLI convention into
> consideration.
>
>
>> Making a change that has a negative effect for everybody, in the hope
>> of sometimes improving performance for something that is already fast
>> doesn't seem a good trade off to me.
>
> Hmm.. I suppose the negative effect you've pointed is possible
> slowing down of hot-standby by the extra checkpoints being
> discussed in another thread, is it correct? Could you accept this
> kind of modification if it could be turned off by, say, GUC?


This proposal is for a performance enhancement. We normally require
some proof that the enhancement is real and that it doesn't have a
poor effect on people not using it. Please make measurements.

It's easy to force more frequent checkpointsif you wish them, so
please compare the case of more frequent checkpoints.


>> Regrettably, the line of thought explained here does not seem useful to me.
>>
>> As you know, I was working on avoiding shutdown checkpoints completely
>> myself. You are welcome to work on the approach Fujii and I discussed.
>
> Sorry, I'm afraid that I've failed to find that discussion. Could
> you let me have a pointer to that? Of cource I'd be very happy if
> the checkpoints are completely avoided on the approach.

Discussion on a patch submitted to me to the Januray 2012 CommitFest
to reduce failover time.

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