Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-27 Thread Tom Lane
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

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-27 Thread Jim Nasby
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

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-27 Thread Jim Nasby
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

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-26 Thread Jim Nasby
On 1/26/15 4:51 PM, Tom Lane wrote: Jim Nasby jim.na...@bluetreble.com writes: On 1/24/15 3:31 PM, Tom Lane 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. paranoia Shouldn't

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-26 Thread Jim Nasby
On 1/24/15 3:31 PM, Tom Lane 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. paranoia Shouldn't this technically tie in with ResourceOwners? If a pointer takes the pin count from 1

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-26 Thread Tom Lane
Jim Nasby jim.na...@bluetreble.com writes: On 1/24/15 3:31 PM, Tom Lane 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. paranoia Shouldn't this technically tie in with

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-26 Thread Greg Stark
On Tue, Jan 27, 2015 at 12:03 AM, Jim Nasby 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

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-24 Thread Peter Geoghegan
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

Re: [HACKERS] Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

2015-01-24 Thread Tom Lane
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