On 22 January 2014 14:25, Simon Riggs <si...@2ndquadrant.com> wrote: > 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.
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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
