Re: Checkpointer on hot standby runs without looking checkpoint_segments
От | Simon Riggs |
---|---|
Тема | Re: Checkpointer on hot standby runs without looking checkpoint_segments |
Дата | |
Msg-id | CA+U5nMK9zw69t6KVJzwYxq2HD_S4vMy6Y5xntFbh19ST-cX45A@mail.gmail.com обсуждение исходный текст |
Ответ на | Checkpointer on hot standby runs without looking checkpoint_segments (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Checkpointer on hot standby runs without looking checkpoint_segments
|
Список | pgsql-hackers |
On 8 June 2012 09:14, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > The requirement for this patch is as follows. > > - What I want to get is similarity of the behaviors between > master and (hot-)standby concerning checkpoint > progression. Specifically, checkpoints for streaming > replication running at the speed governed with > checkpoint_segments. The work of this patch is avoiding to get > unexpectedly large number of WAL segments stay on standby > side. (Plus, increasing the chance to skip recovery-end > checkpoint by my another patch.) Since we want wal_keep_segments number of WAL files on master (and because of cascading, on standby also), I don't see any purpose to triggering more frequent checkpoints just so we can hit a magic number that is most often set wrong. ISTM that we should avoid triggering a checkpoint on the master if checkpoint_segments is less than wal_keep_segments. Such checkpoints serve no purpose because we don't actually limit and recycle the WAL files and all it does is slow people down. Also, I don't believe that throwing more checkpoints makes it more likely we can skip shutdown checkpoints at failover. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: