On Tue, 2004-12-14 at 23:31, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > DEBUG1 messages showed that there is an apparent limit of 255 xlog files
> > per checkpoint -
>
> The volume-based checkpoint trigger code is
>
> if (IsUnderPostmaster &&
> (openLogId != RedoRecPtr.xlogid ||
> openLogSeg >= (RedoRecPtr.xrecoff / XLogSegSize) +
> (uint32) CheckPointSegments))
> {
> #ifdef WAL_DEBUG
> if (XLOG_DEBUG)
> elog(LOG, "time for a checkpoint, signaling bgwriter");
> #endif
> RequestCheckpoint(false);
> }
>
> which now that I look at it obviously forces a checkpoint whenever
> xlogid (the upper half of XLogRecPtr) changes, ie every 4GB of WAL
> output. I suppose on a high-performance platform it's possible that
> one would want checkpoints further apart than that, though the idea
> of plowing through multiple gigabytes of WAL in order to recover from
> a crash is a bit daunting.
>
> It's not immediately obvious how to recast the comparison without
> either creating overflow bugs or depending on 64-bit-int arithmetic
> being available. Thoughts?
Thanks for finding it. It was staring me in the face.
I'd say no code changes for 8.0, now we know what's causing it. A doc
patch to show the limit is probably just going to annoy the translators
at this stage also.
Reasons:
- you can recompile using larger XLogSegSize, if you care to
- the real answer is to reduce the xlog volume
--
Best Regards, Simon Riggs
