| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org, markw(at)osdl(dot)org |
| Subject: | Re: Checkpoints occur too frequently |
| Date: | 2004-12-14 23:31:24 |
| Message-ID: | 24551.1103067084@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Simon Riggs <simon(at)2ndquadrant(dot)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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2004-12-15 00:22:51 | Re: Checkpoints occur too frequently |
| Previous Message | Simon Riggs | 2004-12-14 22:05:36 | Checkpoints occur too frequently |