On Fri, Mar 24, 2017 at 11:52 AM, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: > > > On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> >> Hi, >> In create_unique_path() there's comment >> /* >> * We must ensure path struct and subsidiary data are allocated in >> main >> * planning context; otherwise GEQO memory management causes trouble. >> */ >> oldcontext = MemoryContextSwitchTo(root->planner_cxt); >> >> pathnode = makeNode(UniquePath); >> >> This means that when GEQO resets the memory context, the RelOptInfo >> for which this path is created and may be set to cheapest_unique_path >> goes away, the unique path lingers on in the planner context. >> Shouldn't we instead allocate the path in the same context as the >> RelOptInfo similar to mark_dummy_rel()? >> > > Do you have test case, which can reproduce the issue you > explained above? >
No. It would require some surgery in standard_planner() to measure the memory consumed in the planner context OR build the code with SHOW_MEMORY_STATS defined and dump memory context statistics and check planner context memory usage. I don't think I can produce a testcase quickly right now. But then, I think the problem is quite apparent from the code inspection alone, esp. comparing what mark_dummy_rel() does with what create_unique_path() is doing. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
