Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
Date
Msg-id 20120417.200852.47206121.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Hello,

> The reason we haven't historically obeyed checkpoint_segments
> during recovery is that it slows down the recovery
> unnecessarily if you're restoring from a backup and you replay,

The variable StandbyMode is false on archive recovery, so no
checkpoint triggerred during then.

xlog.c:10026 (in some version around 9.2)
|     /*
|      * Request a restartpoint if we've replayed too much
|      * xlog since the last one.
|      */
|     if (StandbyMode && bgwriterLaunched)
|     {
|       if (XLogCheckpointNeeded(readId, readSeg))

> You could argue that you should obey checkpoint_segments in a
> standby server that's caught up with the master, but AFAICS the
> patch doesn't try to detect that.

Concerning checkpoint, there seems no need for the standby to know
whether it has been caught up with its master or not. Checkpoint has
been already kicked by checkpoint_timeout regardless of the
sync_state.


regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.


pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Slow temporary tables when using sync rep
Next
From: Qi Huang
Date:
Subject: Re: Gsoc2012 idea, tablesample