On Wed, Nov 18, 2015 at 12:59 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Nov 12, 2015 at 10:23 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > Thanks for the report. The reason for this problem is that instrumentation > > information from workers is getting aggregated multiple times. In > > ExecShutdownGatherWorkers(), we call ExecParallelFinish where it > > will wait for workers to finish and then accumulate stats from workers. > > Now ExecShutdownGatherWorkers() could be called multiple times > > (once we read all tuples from workers, at end of node) and it should be > > ensured that repeated calls should not try to redo the work done by first > > call. > > The same is ensured for tuplequeues, but not for parallel executor info. > > I think we can safely assume that we need to call ExecParallelFinish() only > > when there are workers started by the Gathers node, so on those lines > > attached patch should fix the problem. > > I suggest that we instead fix ExecParallelFinish() to be idempotent. > Add a "bool finished" flag to ParallelExecutorInfo and return at once > if it's already set. Get rid of the exposed > ExecParallelReinitializeTupleQueues() interface and have > ExecParallelReinitialize(pei) instead. Have that call > ReinitializeParallelDSM(), ExecParallelSetupTupleQueues(pei->pcxt, > true), and set pei->finished = false. I think that would give us a > slightly cleaner separation of concerns between nodeGather.c and > execParallel.c. >
Okay, attached patch fixes the issue as per above suggestion. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
fix_finish_parallel_executor_info_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
