At Thu, 14 Mar 2019 17:18:29 +0900, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote in
<e7bcef25-317b-75fc-cc63-34e1fbec514b@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_f8@lab.ntt.co.jp> wrote in
<3ad792cd-0805-858e-595c-c09e9d1ce042@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