pgsql: Mark a query's topmost Paths parallel-unsafe if they will have i

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Mark a query's topmost Paths parallel-unsafe if they will have i
Date: 2016-11-25 21:20:41
Message-ID: E1cANvF-0003ZB-V8@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Mark a query's topmost Paths parallel-unsafe if they will have initPlans.

Andreas Seltenreich found another case where we were being too optimistic
about allowing a plan to be considered parallelizable despite it containing
initPlans. It seems like the real issue here is that if we know we are
going to tack initPlans onto the topmost Plan node for a subquery, we
had better mark that subquery's result Paths as not-parallel-safe. That
fixes this problem and allows reversion of a kluge (added in commit
7b67a0a49 and extended in f24cf960d) to not trust the parallel_safe flag
at top level.

Discussion: <874m2w4k5d(dot)fsf(at)ex(dot)ansel(dot)ydns(dot)eu>

Branch
------
REL9_6_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/474de765a8003bc58f5736f626bf533147cc1e68

Modified Files
--------------
src/backend/optimizer/plan/planner.c | 15 ++++++---------
src/backend/optimizer/plan/subselect.c | 9 ++++++---
2 files changed, 12 insertions(+), 12 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-11-25 23:36:26 pgsql: Bring some clarity to the defaults for the xxx_flush_after param
Previous Message Tom Lane 2016-11-25 18:45:17 pgsql: Check for pending trigger events on far end when dropping an FK