Re: Spread checkpoint sync

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spread checkpoint sync
Date: 2010-12-03 00:12:16
Message-ID: AANLkTikdjbyQmRd2229kYc9F8zQDjptoe=z3Csihn03w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 2, 2010 at 2:24 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Wed, Dec 1, 2010 at 4:25 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>>> I ask because I don't have a mental model of how the pause can help.
>>> Given that this dirty data has been hanging around for many minutes
>>> already, what is a 3 second pause going to heal?
>>>
>>
>> The difference is that once an fsync call is made, dirty data is much more
>> likely to be forced out.  It's the one thing that bypasses all other ways
>> the kernel might try to avoid writing the data
>
> I had always assumed the problem was that other I/O had been done to
> the files in the meantime. I.e. the fsync is not just syncing the
> checkpoint but any other blocks that had been flushed since the
> checkpoint started.

It strikes me that we might start the syncs of the files that the
checkpoint isn't going to dirty further at the start of the
checkpoint, and do the rest at the end.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-12-03 00:12:50 Re: DELETE with LIMIT (or my first hack)
Previous Message Robert Haas 2010-12-03 00:10:48 Re: Another proposal for table synonyms