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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy
Дата
Msg-id CAM-w4HP9dtsM8GyoAgZhGLyXWAs30siUpoUg2n6+b6GcO4E0=w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
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?

-- 
greg



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

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: [HACKERS] [PATCH] A hook for session start
Следующее
От: Thom Brown
Дата:
Сообщение: Re: [HACKERS] pg_upgrade failed if view contain natural left join condition