On Fri, 2006-08-18 at 08:52 -0400, Tom Lane wrote:
> 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.
Agreed.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
