Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Дата
Msg-id CAM-w4HP=zo_8cBgUsinUN6+Up7Af73pU-HYuWC21f1y-Zi1Ohw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers

On Tue, Jan 27, 2015 at 12:03 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
But one backend can effectively "pin" a buffer more than once, no? If so, then ISTM there's some risk that code path A pins and forgets to unpin, but path B accidentally unpins for A.

The danger is that there's a codepath that refers to memory it doesn't have a pin on but that there is no actual test in our regression suite that doesn't actually have a second pin on the same buffer. If there is in fact no reachable code path at all without the second pin then there's no active bug, only a bad coding practice. But if there are code paths that we just aren't testing then that's a real bug.

IIRC CLOBBER_FREED_MEMORY only affects palloc'd blocks. Do we not have a mode that automatically removes any buffer as soon as it's not pinned? That seems like it would be a valuable addition.

Fwiw I think our experience is that bugs where buffers are unpinned get exposed pretty quickly in production. I suppose the same might not be true for rarely called codepaths or in cases where the buffers are usually already pinned.


--
greg

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: pg_upgrade and rsync
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: ExplainModifyTarget doesn't work as expected