plpgsql: Don't generate parallel plans for RETURN QUERY.

Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel
plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE
statement in a PL/pgsql block, but that's a bad idea because plplgsql
asks the executor for 50 rows at a time.  That means that we'll always
be running serially a plan that was intended for parallel execution,
which is not a good idea.  Fix by not requesting a parallel plan from
the outset.

Per discussion, back-patch to 9.6.  There is a slight risk that, due
to optimizer error, somebody could have a case where the parallel plan
executed serially is actually faster than the supposedly-best serial
plan, but the consensus seems to be that that's not sufficient
justification for leaving 9.6 unpatched.

Discussion: http://postgr.es/m/CA+TgmoZ_ZuH+auEeeWnmtorPsgc_SmP+XWbDsJ+cWvWBSjNwDQ@mail.gmail.com
Discussion: http://postgr.es/m/CA+TgmobXEhvHbJtWDuPZM9bVSLiTj-kShxQJ2uM5GPDze9fRYA@mail.gmail.com

diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 49a4e622ffd1585e3dcfc03061b259efa21f831b..8e836a81494cbfd9ff0367e3e8bc26a91b7a8307 100644 (file)
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -3023,7 +3023,7 @@ exec_stmt_return_query(PLpgSQL_execstate *estate,
    if (stmt->query != NULL)
    {
        /* static query */
-       exec_run_select(estate, stmt->query, 0, &portal, true);
+       exec_run_select(estate, stmt->query, 0, &portal, false);
    }
    else
    {
@@ -3031,7 +3031,7 @@ exec_stmt_return_query(PLpgSQL_execstate *estate,
        Assert(stmt->dynquery != NULL);
        portal = exec_dynquery_with_params(estate, stmt->dynquery,
                                           stmt->params, NULL,
-                                          CURSOR_OPT_PARALLEL_OK);
+                                          0);
    }
 
    /* Use eval_mcontext for tuple conversion work */