On 20 July 2017 at 14:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@mit.edu> writes: > >> Would it be useful to keep in one of the memory checking assertion builds? > > Why? Code that expects to continue accessing a relcache entry's tupdesc > after closing the relcache entry is broken, independently of whether it's > in a debug build or not.
Mea Culpa. I hadn't actually read the code and assumed it would be sensible to change from something that freed these tupdescs into something that raised an assertion if they were still unfreed at end of transaction. Reading the code I see that it's only there to *avoid* freeing the tupledesc just in case there's something still using it. If we just free it then the normal memory checking builds would catch cases where they're used after being freed. But what I still don't understand is whether the fact that it still passes the regression tests means anything. Unless there happened to be a sinval message at the wrong time the regression tests wouldn't uncover any problem cases. If it passed the tests on a CLOBBER_CACHE_ALWAYS build then perhaps that would prove it's safe? Or perhaps if the columns haven't actually been altered it would still fail to fail? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
