On Wed, Jul 17, 2019 at 6:28 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Wed, Jul 17, 2019 at 12:44 PM Thomas Munro <thomas.mu...@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
