On 22 January 2014 14:25, Simon Riggs <[email protected]> wrote: > On 22 January 2014 13:14, Heikki Linnakangas <[email protected]> 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
