Simon Riggs <simon@2ndquadrant.com> writes:
> On Thu, 2006-08-17 at 19:11 -0400, Tom Lane wrote:
>> I noticed a minor annoyance while testing: when the system is completely
>> idle, you get a forced segment switch every checkpoint_timeout seconds,
>> even though there is nothing useful to log. The checkpoint code is
>> smart enough not to do a checkpoint if nothing has happened since the
>> last one, and the xlog switch code is smart enough not to do a switch
>> if nothing has happened since the last one ... but they aren't talking
>> to each other and so each one's change looks like "something happened"
>> to the other one.
> I noticed that minor annoyance and understood that I had fixed it before
> submitting. That was the reason for putting the code in bgwriter to
> check whether the pointer had moved before attempting the switch...
> perhaps that functionality has been removed?
No, the original form of the patch was equally vulnerable. AFAICS the
only way to prevent this would be for XLogRequestSwitch (or really
XLogInsert, which does the heavy lifting for this) to suppress a switch
if the current segment is empty *or* contains only a checkpoint WAL
record. Basically it'd have to pretend the checkpoint record is not
there. This is doable but seems a bit weird --- in particular, that
would mean that pg_switch_xlog sometimes returns a pointer less than
pg_current_xlog_location, which might confuse backup scripts.
On the whole I'm leaning towards not changing it. As Florian mentioned,
guaranteed segment-every-checkpoint isn't completely without its uses.
And people who are looking for low WAL volume ought to be stretching
out their checkpoint intervals anyway.
regards, tom lane