Re: Redesigning checkpoint_segments

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Redesigning checkpoint_segments
Дата
Msg-id 1370521886.31391.YahooMailNeo@web162904.mail.bf1.yahoo.com
обсуждение исходный текст
Ответ на Re: Redesigning checkpoint_segments  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Redesigning checkpoint_segments  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Freezing without write I/O
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Freezing without write I/O