On Wed, Jul 17, 2019 at 4:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.
>
I am not able to come up with anything better. Robert, Thomas, do you
see any problem with this idea or do you have any better ideas to fix
this issue?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com