Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Дата
Msg-id 9912.1422400590@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 1/26/15 6:11 PM, Greg Stark wrote:
>> Fwiw I think our experience is that bugs where buffers are unpinned get exposed pretty quickly in production. I
supposethe same might not be true for rarely called codepaths or in cases where the buffers are usually already
pinned.

> Yeah, that's what I was thinking. If there's some easy way to correctly associate pins with specific code paths
(owners?)then maybe it's worth doing so; but I don't think it's worth much effort.
 

If you have a working set larger than shared_buffers, then yeah it's
likely that reference-after-unpin bugs would manifest pretty quickly.
This does not necessarily translate into something reproducible or
debuggable, however; and besides that you'd really rather that such
bugs not get into the field in the first place.

The point of my Valgrind proposal was to provide a mechanism that would
have a chance of catching such bugs in a *development* context, and
provide some hint of where in the codebase the fault is, too.
        regards, tom lane



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: proposal: row_to_array function
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: jsonb, unicode escapes and escaped backslashes