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

From Simon Riggs
Subject Re: Checkpointer on hot standby runs without looking checkpoint_segments
Date
Msg-id CA+U5nMK9zw69t6KVJzwYxq2HD_S4vMy6Y5xntFbh19ST-cX45A@mail.gmail.com
Whole thread Raw
In response to Checkpointer on hot standby runs without looking checkpoint_segments  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Checkpointer on hot standby runs without looking checkpoint_segments
List 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 by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: New Postgres committer: Kevin Grittner
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: New Postgres committer: Kevin Grittner