At Thu, 14 Mar 2019 17:18:29 +0900, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote in <e7bcef25-317b-75fc-cc63-34e1fbec5...@lab.ntt.co.jp> > On 2019/03/14 16:46, Amit Langote wrote: > > On 2019/03/14 16:32, Kyotaro HORIGUCHI wrote: > >> At Thu, 14 Mar 2019 16:13:23 +0900, Amit Langote > >> <langote_amit...@lab.ntt.co.jp> wrote in > >> <3ad792cd-0805-858e-595c-c09e9d1ce...@lab.ntt.co.jp> > >>> Hi, > >>> > >>> I'm curious why DestroyPartitionDirectory doesn't do > >>> hash_destroy(pdir->pdir_hash)? > >> > >> Maybe it is trashed involved in destruction of es_query_cxt or > >> planner_cxt? > > > > Hmm, the executor's partition directory (its hash table) is indeed > > allocated under es_query_cxt. But, the planner's partition directory is > > not allocated under planner_cxt, it appears to be using memory under > > MessageContext.
CurrentMemoryContext? It is PortalContext while planning CLUSTER scan. And it seems to be the same with planner_cxt with several narrow exceptions.. I think everything linked from PlannrInfo ought to be allocated in the top planner's planner_cxt if finally not expilcitly delinked and I *believe* subquery's planner_cxt is always same with that of the top-level subquery_planner. > I forgot to mention that it would be wrong to put it under planner_cxt, as > it's the context for planning a given subquery, whereas a partition > directory is maintained throughout the whole planning. So if the ParitionDirectory is allocaed explicitly in MessageContext, it would be danger on CLUSTER command. But as I see in the code, if it is in CurrentMemoryContext it would be safe but I think it should be fixed to use planner_cxt. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
