Re: Redesigning checkpoint_segments

On Thu, Jun 6, 2013 at 1:42 AM, Joshua D. Drake <jd(at)commandprompt(dot)com>wrote:

>
>
> 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.

Cheers,

Jeff