Skip site navigation (1) Skip section navigation (2)

Re: Load Distributed Checkpoints, final patch

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Glaesemann <grzm(at)seespotcode(dot)net>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Load Distributed Checkpoints, final patch
Date: 2007-06-26 20:49:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> We could just allow any value up to 1.0, and note in the docs that you 
>> should leave some headroom, unless you don't mind starting the next 
>> checkpoint a bit late. That actually sounds pretty good.
> Yeah, that sounds fine.  There isn't actually any harm in starting a
> checkpoint later than otherwise expected, is there?  The worst
> consequence I can think of is a backend having to take time to
> manufacture a new xlog segment, because we didn't finish a checkpoint
> in time to recycle old ones.  This might be better handled by allowing
> a bit more slop in the number of recycled-into-the-future xlog segments.
> Come to think of it, shouldn't we be allowing some extra slop in the
> number of future segments to account for xlog archiving delays, when
> that's enabled?

XLogFileSlop is currently 2 * checkpoint_segments + 1 since last 
checkpoint, which is just enough to accommodate a checkpoint that lasts 
the full checkpoint interval. If we want to keep as much "slop" there as 
before, then yes that should be increased to (2 + 
checkpoint_completion_target) * checkpoint_segments + 1, or just 3 * 
checkpoint_segments if we want to keep it simple.

   Heikki Linnakangas

In response to

pgsql-patches by date

Next:From: Greg SmithDate: 2007-06-26 21:46:30
Subject: Re: Load Distributed Checkpoints, take 3
Previous:From: Tom LaneDate: 2007-06-26 20:44:01
Subject: Re: Load Distributed Checkpoints, final patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group