Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy
Date: 2017-07-21 02:35:56
Message-ID: 946544e1-a4d7-12b5-60c6-c2b5f956ec6a@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 2017/07/20 22:19, Tom Lane wrote:
> Greg Stark <stark(at)mit(dot)edu> writes:
>> On 19 July 2017 at 00:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2017-07-21 02:42:33 Re: Backward compatibility
Previous Message Igor Korot 2017-07-21 02:23:57 Re: Backward compatibility

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2017-07-21 03:00:03 Re: Mishandling of WCO constraints in direct foreign table modification
Previous Message Craig Ringer 2017-07-21 02:11:05 Re: xlogfilename