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

From Tom Lane
Subject Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Date
Msg-id 22209.1422135074@sss.pgh.pa.us
Whole thread Raw
Responses Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
List pgsql-hackers
While the CLOBBER_FREED_MEMORY hack does a fairly good job of catching
stale pointers to already-freed memory, commit fd496129d160950e exhibits
a case that is not caught at all: RelationBuildRowSecurity was copying
*pointers into disk buffers* into backend-local relcaches.  This would
of course work just as long as the relevant system catalog pages stayed
in shared buffers ... which is probably long enough that you'd never
notice it in typical developer testing.

I wonder if there's anything we can do to catch such cases more
mechanically?

One brute-force answer is to run the regression tests with a very small
shared_buffers setting; but it's not clear what is small enough, nor
what might be so small as to cause failures.

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.  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?

Ideas?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WIP: multivariate statistics / proof of concept
Next
From: Peter Geoghegan
Date:
Subject: Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers