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+U5nMLevTx7audPH55z+vTYBmVSMPHPb6mX1wr6d76QiGuUWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hard limit on WAL space used (because PANIC sucks)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 22 January 2014 14:25, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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.

This could be handled similarly to the way we handle buffer pin
deadlocks in Hot Standby.

So I don't see any blockers from that angle.

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



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: David Rowley
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)