Re: [PATCHES] WIP archive_timeout patch
От | Simon Riggs |
---|---|
Тема | Re: [PATCHES] WIP archive_timeout patch |
Дата | |
Msg-id | 1157368351.2749.52.camel@holly обсуждение исходный текст |
Ответ на | Re: [PATCHES] WIP archive_timeout patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: