Re: WAL Rate Limiting

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL Rate Limiting
Дата
Msg-id 28289.1389889168@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL Rate Limiting  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: WAL Rate Limiting  (Andres Freund <andres@2ndquadrant.com>)
Re: WAL Rate Limiting  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-01-16 17:47:51 +0200, Heikki Linnakangas wrote:
>> In suitable safe places, check if you've written too much WAL, and sleep if
>> so.

> That'd be most places doing XLogInsert() if you want to be
> consistent.

See my other response.  There's no need for "consistency", only to be sure
that code paths that might generate a *lot* of WAL include such checks.
We've gotten along fine without any formal methodology for where to put
CHECK_FOR_INTERRUPTS() or vacuum_delay_point() calls, and this seems like
just more of the same.

> I think the usecases that would want this for DML probably also wan this
> to work for unlogged, temp tables.

Huh?  Unlogged tables generate *zero* WAL, by definition.

If your point is that WAL creation isn't a particularly good resource
consumption metric, that's an argument worth considering, but it seems
quite orthogonal to whether we can implement such throttling reasonably.
And in any case, you didn't provide such an argument.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it