Horton

Re: Spread checkpoint sync

Kevin Grittner <kevin.grittner@wicourts.gov>

View thread
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Robert Haas" <robertmhaas@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Greg Smith" <greg@2ndquadrant.com>, "Josh Berkus" <josh@agliodbs.com>, "Ron Mayer" <rm_pg@cheapcomplexdevices.com>, "Heikki Linnakangas" <heikki.linnakangas@enterprisedb.com>, "Itagaki Takahiro" <itagaki.takahiro@gmail.com>, <pgsql-hackers@postgresql.org>
Date: 2011-02-01T17:58:52Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add new buffers_backend_fsync field to pg_stat_bgwriter.

Robert Haas <robertmhaas@gmail.com> wrote:
 
> I also think Bruce's idea of calling fsync() on each relation just
> *before* we start writing the pages from that relation might have
> some merit.
 
What bothers me about that is that you may have a lot of the same
dirty pages in the OS cache as the PostgreSQL cache, and you've just
ensured that the OS will write those *twice*.  I'm pretty sure that
the reason the aggressive background writer settings we use have not
caused any noticeable increase in OS disk writes is that many
PostgreSQL writes of the same buffer keep an OS buffer page from
becoming stale enough to get flushed until PostgreSQL writes to it
taper off.  Calling fsync() right before doing "one last push" of
the data could be really pessimal for some workloads.
 
-Kevin