Peter Geoghegan <p...@heroku.com> writes:
> On Sat, Jan 24, 2015 at 1:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Another idea is to teach Valgrind that whenever a backend reduces its
>> pin count on a shared buffer to zero, that buffer should become undefined
>> memory.
> That should be fairly straightforward to implement.
>> But I don't know if that will help --- if the buffer is then
>> re-accessed, is Valgrind able to distinguish freshly-computed pointers
>> into it from stale ones?
> I don't think so. However, I think that
> VALGRIND_CHECK_VALUE_IS_DEFINED() might be used. I believe you could
> have Valgrind builds deference a pointer, and make sure that it
> pointed into defined memory. But what would the generally useful choke
> points for such a check be?
Not sure. There are wide swaths of the system where it would be perfectly
valid to see a pointer into buffer storage, so long as you still had a pin
on that page.
However, after further consideration it seems like even without solving
the buffer-reaccess problem, a Valgrind tweak such as above would have
caught this bug, and probably most other similar bugs. Running with a
large shared_buffers value actually works in our favor for this: you're
unlikely to get aliasing between different pages occupying the same
buffer. And most queries don't (intentionally) re-access the same page,
so while detection of a stale pointer wouldn't be certain it'd be fairly
probable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
