On Fri, 2006-08-18 at 08:52 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
