[HACKERS] parallel index(-only) scan breaks when run without parallelism - Mailing list pgsql-hackers

From Robert Haas
Subject [HACKERS] parallel index(-only) scan breaks when run without parallelism
Date
Msg-id CA+TgmoYiz+8pnGZ_+YGiKQ6t4ni+=4M4HNO4qJTO85zi7zc_Tw@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] parallel index(-only) scan breaks when run without parallelism  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Amit, Rafia,

nodeIndexscan.c, unlike nodeSeqscan.c, thinks that a parallel-aware
scan will always be executed in parallel mode.  But that's not true:
an Execute message with a non-zero row count could cause us to abandon
planned parallelism and execute the plan serially.   I believe this
would cause a core dump.  We definitely core dump with the following
small patch, which causes parallelism to always be abandoned:

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index f5cd65d..fc4de48 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -1596,8 +1596,7 @@ ExecutePlan(EState *estate,     * when writing into a relation, because no database changes are
allowed    * in parallel mode.     */
 
-    if (numberTuples || dest->mydest == DestIntoRel)
-        use_parallel_mode = false;
+    use_parallel_mode = false;
    if (use_parallel_mode)        EnterParallelMode();

I believe this defect was introduced by
5262f7a4fc44f651241d2ff1fa688dd664a34874 and that nodeIndexonlyscan.c
has the same defect as of 0414b26bac09379a4cbf1fbd847d1cee2293c5e4.

Please fix.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Poor memory context performance in large hash joins
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed