Thread: [HACKERS] parallel index(-only) scan breaks when run without parallelism

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

On Wed, Mar 8, 2017 at 12:27 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
>

Right, and the current code had assumed that if there is a parallel
plan then it will always enter the parallel mode.   I think the fix is
quite similar to what we do in nodeSeqscan.c i.e. initialize the scan
descriptor before starting the scan if it is not already initialized.
 There is an additional check required for ensuring if index runtime
keys are ready before calling index_rescan.  Attached patch fixes the
problem.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers