Re: Hard limit on WAL space used (because PANIC sucks)

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Hard limit on WAL space used (because PANIC sucks)
Дата
Msg-id CA+U5nMJqBpZ_2Z_RX2DeLx+sey4-tqTLuttOB_6p5Gf9qaohxw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hard limit on WAL space used (because PANIC sucks)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Hard limit on WAL space used (because PANIC sucks)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 22 January 2014 13:14, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> On 01/22/2014 02:10 PM, Simon Riggs wrote:
>>
>> As Jeff points out, the blocks being modified would be locked until
>> space is freed up. Which could make other users wait. The code
>> required to avoid that wait would be complex and not worth any
>> overhead.
>
>
> Checkpoint also acquires the content lock of every dirty page in the buffer
> cache...

Good point. We would need to take special action for any dirty blocks
that we cannot obtain content lock for, which should be a smallish
list, to be dealt with right at the end of the checkpoint writes.

We know that anyone waiting for the WAL lock will not be modifying the
block and so we can copy it without obtaining the lock. We can inspect
the lock queue on the WAL locks and then see which buffers we can skip
the lock for.

The alternative of adding a check for WAL space to the normal path is
a non-starter, IMHO.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [bug fix] pg_ctl always uses the same event source
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Add min and max execute statement time in pg_stat_statement