Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Date
Msg-id 54C6BE29.4070507@BlueTreble.com
Whole thread Raw
In response to Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
List pgsql-hackers
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 to 2, then that pointer
shouldbe invalid by the time the pin count goes from 2 to 1...
 

I'm worried that a simple test when pin count is 0 could miss some cases of pointers just happening to be cleared by a
secondpart of the code even though the pin count has already dropped.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL
Next
From: Stephen Frost
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL