Re: Hard limit on WAL space used (because PANIC sucks)
От | Simon Riggs |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | CA+U5nMLevTx7audPH55z+vTYBmVSMPHPb6mX1wr6d76QiGuUWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On 22 January 2014 14:25, Simon Riggs <simon@2ndquadrant.com> wrote: > 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. 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
В списке pgsql-hackers по дате отправления: