Re: Memory Leaks in query_planner in postgresql 9.4 version

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gourav Kumar <gourav1905(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory Leaks in query_planner in postgresql 9.4 version
Date: 2018-04-21 14:57:38
Message-ID: 18442.1524322658@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gourav Kumar <gourav1905(at)gmail(dot)com> writes:
> I have modified the PostgreSQL source code for my project implementation.
> In the modified code, I am calling query_planner function several times
> while I am inside the grouping planner function.

> As the number of executions increase I have noticed memory leaks in the
> code. I have pinpointed it to be inside the query_planner, using the
> heaptrack tool. But, I am unable to figure out the exact location of it.

The planner eats memory like there's no tomorrow. This is intentional;
it'd be nearly impossible to release very much given the intertwining
of its data structures.

You might be able to do something similar to what GEQO does, and run
speculative planning calls inside a short-lived memory context that you
can reset after each run. The trick there would be to draw a line
between what the speculative calls modify and don't modify. I'm afraid
GEQO's line isn't very close to what you need, if you're hoping to repeat
all of query_planner(). Also you're going to have lots of problems with
query_planner changing the input Query tree.

Personally I'd suggest not going in that direction, but instead think in
terms of having query_planner return more Paths.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-04-21 15:27:48 Re: Searching for: Fast windows buildfarm animal
Previous Message Pavan Deolasee 2018-04-21 14:30:10 Re: Toast issues with OldestXmin going backwards