Re: Hard limit on WAL space used (because PANIC sucks) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hard limit on WAL space used (because PANIC sucks)
Date
Msg-id CA+U5nMJqBpZ_2Z_RX2DeLx+sey4-tqTLuttOB_6p5Gf9qaohxw@mail.gmail.com
Whole thread Raw
In response to Re: Hard limit on WAL space used (because PANIC sucks)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Hard limit on WAL space used (because PANIC sucks)  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [bug fix] pg_ctl always uses the same event source
Next
From: Robert Haas
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement