On Wed, Jul 17, 2019 at 6:28 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Wed, Jul 17, 2019 at 12:44 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > > #11 0x000055666e0359df in ExecShutdownNode (node=node@entry=0x55667033a6c8)
> > > at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/execProcnode.c:830
> > > #12 0x000055666e04d0ff in ExecLimit (node=node@entry=0x55667033a428)
> > > at /build/postgresql-9.6-5O8OLM/postgresql-9.6-9.6.14/build/../src/backend/executor/nodeLimit.c:139
> >
> > https://github.com/postgres/postgres/blob/REL9_6_STABLE/src/backend/executor/nodeLimit.c#L139
> >
> > Limit thinks it's OK to "shut down" the subtree, but if you shut down a
> > Gather node you can't rescan it later because it destroys its shared
> > memory. Oops. Not sure what to do about that yet.
>
Yeah, that is a problem. Actually, what we need here is to
wait-for-workers-to-finish and collect all the instrumentation
information. We don't need to destroy the shared memory at this
stage, but we don't have a special purpose function which can just
allow us to collect stats. One idea could be that we create a special
purpose function which sounds like a recipe of code duplication,
another could be that somehow pass the information through
ExecShutdownNode to Gather/GatherMerge that they don't destroy shared
memory. Immediately, I can't think of better ideas, but it is
possible that there is some better way to deal with this.
> CCing Amit and Robert, authors of commits 19df1702 and 69de1718.
>
Thanks for diagnosing the issue.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
