Re: Redesigning checkpoint_segments - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Redesigning checkpoint_segments
Date
Msg-id 1370521886.31391.YahooMailNeo@web162904.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: Redesigning checkpoint_segments  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Redesigning checkpoint_segments
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> On 05.06.2013 22:18, Kevin Grittner wrote:
>> Heikki Linnakangas<hlinnakangas@vmware.com>  wrote:
>>
>>> I was not thinking of making it a hard limit. It would be just
>>> like checkpoint_segments from that point of view - if a
>>> checkpoint takes a long time, max_wal_size might still be
>>> exceeded.
>>
>> Then I suggest we not use exactly that name.  I feel quite sure we
>> would get complaints from people if something labeled as "max" was
>> exceeded -- especially if they set that to the actual size of a
>> filesystem dedicated to WAL files.
>
> You're probably right. Any suggestions for a better name?
> wal_size_soft_limit?

After reading later posts on the thread, I would be inclined to
support making it a hard limit and adapting the behavior to match.
I'm pretty sure I've seen at least one case where a separate
filesystem has been allocated for WAL which has been unexpectedly
filled.  People would like some way to deal with that.

I'm also concerned about the "spin up" from idle to high activity.
Perhaps a "min" should also be present, to mitigate repeated short
checkpoint cycles for "bursty" environments?

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Freezing without write I/O
Next
From: Heikki Linnakangas
Date:
Subject: Re: Freezing without write I/O