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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy
Дата
Msg-id 6051.1500556750@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy  (Greg Stark <stark@mit.edu>)
Ответы Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of tableheirarchy  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy  (Greg Stark <stark@mit.edu>)
Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On 19 July 2017 at 00:26, Tom Lane <tgl@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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeevan Ladhe
Дата:
Сообщение: Re: [HACKERS] Adding support for Default partition in partitioning
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise