Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id CAKJS1f836D=r5w6VgPOdiueYvjTnuUdqpcbfWyAYw5+CUVTXfA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Runtime Partition Pruning  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 13 April 2018 at 04:57, Robert Haas <robertmhaas@gmail.com> wrote:
> BTW, looking at ExecSetupPartitionPruneState:
>
>         /*
>          * Create a sub memory context which we'll use when making calls to the
>          * query planner's function to determine which partitions will
> match.  The
>          * planner is not too careful about freeing memory, so we'll ensure we
>          * call the function in this context to avoid any memory leaking in the
>          * executor's memory context.
>          */
>
> This is a sloppy cut-and-paste job, not only because somebody changed
> one copy of the word "planner" to "executor" and left the others
> untouched, but also because the rationale isn't really correct for the
> executor anyway, which has memory contexts all over the place and
> frees them all the time.  I don't know whether the context is not
> needed at all or whether the context is needed but the rationale is
> different, but I don't buy that explanation.

The comment is written exactly as intended. Unsure which of the
"planner"s you think should be "executor".

The context is needed. I can easily produce an OOM without it.



-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: crash with sql language partition support function
Следующее
От: Thomas Munro
Дата:
Сообщение: Instability in partition_prune test?