On 1/26/15 6:11 PM, Greg Stark wrote:
On Tue, Jan 27, 2015 at 12:03 AM, Jim Nasby <jim.na...@bluetreble.com
<mailto:jim.na...@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.
By setting BufferDesc.tag to 0?
On a related note... I'm confused by this part of UnpinBuffer. How is refcount
ending up > 0??
Assert(ref->refcount > 0);
ref->refcount--;
if (ref->refcount == 0)
{
/* I'd better not still hold any locks on the buffer */
Assert(!LWLockHeldByMe(buf->content_lock));
Assert(!LWLockHeldByMe(buf->io_in_progress_lock));
LockBufHdr(buf);
/* Decrement the shared reference count */
Assert(buf->refcount > 0);
buf->refcount--;
BTW, I certainly see no evidence of CLOBBER_FREED_MEMORY coming into play here.
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.
--
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
