Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
Дата
Msg-id 20120417.200852.47206121.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Slow temporary tables when using sync rep
Следующее
От: Qi Huang
Дата:
Сообщение: Re: Gsoc2012 idea, tablesample