8.6. Flushing Dirty Pages
In addition to replacing victim pages, the checkpointer and background writer processes flush dirty pages to storage. Both processes have the same function, flushing dirty pages, but they have different roles and behaviors.
The checkpointer process writes a checkpoint record to the WAL segment file and flushes dirty pages whenever checkpointing starts. Section 9.7 describes checkpointing and when it begins.
The role of the background writer is to reduce the impact of the intensive writing of checkpointing. The background writer continues to flush dirty pages little by little with minimal impact on database activity. By default, the background writer wakes every 200 msec (defined by bgwriter_delay) and flushes bgwriter_lru_maxpages (the default is 100 pages) at most.
In versions 9.1 or earlier, background writer had regularly done the checkpoint processing.
In version 9.2, the checkpointer process has been separated from the background writer process. Since the reason is described in the proposal whose title is “Separating bgwriter and checkpointer”, the sentences from it are shown in the following.
Currently(in 2011) the bgwriter process performs both background writing, checkpointing and some other duties. This means that we can’t perform the final checkpoint fsync without stopping background writing, so there is a negative performance effect from doing both things in one process.
Additionally, our aim in 9.2 is to replace polling loops with latches for power reduction. The complexity of the bgwriter loops is high and it seems unlikely to come up with a clean approach using latches.
(snip)