I may be confused but it is my understanding that bgwriter writes out the data from the shared buffer cache that is dirty based on an interval and a max pages written.
It primarily writes out based on how many buffers have recently needed to be evicted in order to make room to read in new ones. There are secondary clamp limits based on an interval (it does enough work to circle the buffer pool once every 2 minutes) and another on max pages written but the main one is based on recent usage. I've never really understood the point of those secondary clamps.
This makes sense except I don't see a need for the parameter. Why not just specify how the algorithm works and adhere to that without the need for another GUC?
Because you want to limit the amount of disk space used for WAL. It's a soft limit, but still.
Why? This is the point that confuses me. Why do we care? We don't care how much disk space PGDATA takes... why do we all of a sudden care about pg_xlog?
Presumably someone cares about disk space of PGDATA, but it is probably a different person, at a different time, on a different time scale. PGDATA is a long term planning issue, pg_xlog is an operational issue. If the checkpoint had completed 30 seconds earlier or the archive_command had completed 30 seconds earlier (or the commit rate had been throttled for 30 seconds), then pg_xlog would not have run out of space in the first place. Having averted the crisis, maybe it will never arise again, or maybe it will but we will be able to avoid it again. If we delay running out of room on PGDATA for 30 seconds, well, we still ran out of room.
