On Mon, 18 Feb 2008, Peter Schuller wrote:
Am I interpreting that correctly in that dirty buffers need to be flushed to disk at checkpoints? That makes perfect sense - but why would that not be the case with OS buffers?
All the dirty buffers in the cache are written out as part of the checkpoint process--all at once in earlier versions, spread out based on checkpoint_completion_target in 8.3. In the worst case you could theoretically have to write the entire shared_buffer cache out, however big it is, if you managed to get it all dirty just before the checkpoint.
Ultimately everything written to the database (again, with the exception of non-standard direct I/O setups) passes through the OS buffers, so in that respect the OS buffers will also be flushed when the checkpoint does its cleansing fsync.
But dirty buffers for less popular pages do get written before the checkpoint occurs. As there is a need to allocate new pages for the database to work with, it evicts pages in order to find space, and if the page given the boot is dirty it gets written to the OS buffer cache. Those writes trickle out to disk in advance of the checkpoint itself. If you've pushed the majority of memory into the PostgreSQL cache, that won't happen as much (more shared_buffers=>less evictions+less OS cache) and there's a potential for longer, more intensive checkpoints.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
