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
Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy |
Список | 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 по дате отправления: