On 2017/07/20 22:19, Tom Lane wrote: > Greg Stark <st...@mit.edu> writes: >> On 19 July 2017 at 00:26, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> It's probably a bit late in the v10 cycle to be taking any risks in >>> this area, but I'd vote for ripping out RememberToFreeTupleDescAtEOX >>> as soon as the v11 cycle opens, unless someone can show an example >>> of non-broken coding that requires it. (And if so, there ought to >>> be a regression test incorporating that.) > >> 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.
Am I wrong in thinking that TupleDesc refcounting (along with resowner tracking) allows one to use a TupleDesc without worrying about the lifetime of its parent relcache entry? I'm asking this independently of the concerns being discussed in this thread about having the RememberToFreeTupleDescAtEOX() mechanism on top of TupleDesc refcounting. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
