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+U5nMJqBpZ_2Z_RX2DeLx+sey4-tqTLuttOB_6p5Gf9qaohxw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Hard limit on WAL space used (because PANIC sucks)
|
Список | 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 по дате отправления: