On 1/27/15 5:16 PM, Tom Lane wrote:
Jim Nasby <jim.na...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
