Mark a query's topmost Paths parallel-unsafe if they will have initPlans.
authorTom Lane <[email protected]>
Fri, 25 Nov 2016 21:20:12 +0000 (16:20 -0500)
committerTom Lane <[email protected]>
Fri, 25 Nov 2016 21:20:12 +0000 (16:20 -0500)
commitab77a5a4561fad847af4a101a29c922c66449870
tree7f9d5a345c454232859e3b6847e8b02b4323e692
parent4e026b32d4024b03856b4981b26c747b7fef7afb
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: <[email protected]>
src/backend/optimizer/plan/planner.c
src/backend/optimizer/plan/subselect.c