On 22 January 2014 13:14, Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
