Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

On 1/27/15 5:16 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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 suppose the 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.

That's what I was looking for two; I was just wondering if there was an easy way to also cover the case of one path forgetting to Unpin and a second path accidentally Unpinning (with neither dropping the refcount to 0). It sounds like it's just not worth worrying about that though.

Do you think there's merit to having bufmgr.c do something special when refcount hits 0 in a CLOBBER_FREED_MEMORY build? It seems like it's a lot easier to enable that than to setup valgrind (though I've never tried the latter).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com