Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Date: 2015-01-27 22:30:46
Message-ID: 54C81196.8000509@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/26/15 6:11 PM, Greg Stark wrote:
>
> On Tue, Jan 27, 2015 at 12:03 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com <mailto:Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-01-27 22:45:55 Re: WITH CHECK and Column-Level Privileges
Previous Message Stephen Frost 2015-01-27 21:46:44 Re: Parallel Seq Scan