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
|
Список | 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 по дате отправления: