Re: [HACKERS] Runtime Partition Pruning

On Thu, Apr 12, 2018 at 6:01 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On 13 April 2018 at 04:57, Robert Haas <robertmhaas(at)gmail(dot)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.

Oh, crap. You know, I totally misread what that comment was trying to
say. Sorry.

But I wonder why it's the executor's job to clean up after the
planner, instead of adjusting the relevant planner functions to avoid
leaking memory?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company