On Wed, Oct 27, 2010 at 5:01 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> You have to put the WAL files *somewhere* while you do the base backup.
>> PostgreSQL can't itself work out where that is, nor can it work out
>> ahead of time how big it will need to be, since it is up to you how you
>> do your base backup. Setting a parameter to -1 doesn't make the problem
>> go away, it just pretends and hopes it doesn't exist, but screws you
>> badly if you do hit the wall.
>
> Agreed. That's why I like the idea of having a
> max_wal_size/min_wal_time instead of keep_wal_segments or
> checkpoint_segments. It's relatively simple for a DBA to know how much
> disk space s/he has for WAL, total, before locking up the system.
>
> And to answer Robert's question, because now I understand what he was
> getting at. The reason we want a min_wal_time is because we don't want
> to keep a larger WAL around always. If more WAL were always better,
> then we'd only need max_wal_size and we'd only recycle when we hit it.
> Instead, we'd recycle whenever we passed max_wal_time. That's why I
> said that I was assuming nothing of the sort.
I sort of agree with you that the current checkpoint_segments
parameter is a bit hard to tune, at least if your goal is to control
the amount of disk space that will be used by WAL files. But I'm not
sure your proposal is better. Instead of having a complicated formula
for predicting how much disk space would get used by a given value for
checkpoint_segments, we'd have a complicated formula for the amount of
WAL that would force a checkpoint based on max_wal_size.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company