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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 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-20 13:19:10
Message-ID: 6051.1500556750@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2017-07-20 13:33:50 Re: How to stop array_to_json from interpolating column names that weren't there
Previous Message Greg Stark 2017-07-20 12:39:11 Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-07-20 13:28:45 Re: autovacuum can't keep up, bloat just continues to rise
Previous Message Jeevan Ladhe 2017-07-20 13:17:37 Re: Adding support for Default partition in partitioning