From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers |
Date: | 2015-01-27 23:16:30 |
Message-ID: | 9912.1422400590@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2015-01-27 23:18:55 | Re: jsonb, unicode escapes and escaped backslashes |
Previous Message | Jim Nasby | 2015-01-27 23:16:02 | Re: proposal: row_to_array function |