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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
