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
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 |
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 |