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

On 22 January 2014 14:25, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 22 January 2014 13:14, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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