On Thu, May 12, 2016 at 7:46 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On further analysis, I think I know what is going on in the original bug > report. We add the Vars (build_base_rel_tlists) and PlaceholderVars > (add_placeholders_to_base_rels()) to each relations (RelOptInfo) target > during qurey_planner and the Subplans are added as PlaceHolderVars in target > expressions. Now while considering whether a particular rel can be parallel > in set_rel_consider_parallel(), we don't check the target expressions to > allow the relation for parallelism. I think we can prohibit the relation to > be considered for parallelism if it's target expressions contain any > parallel restricted clause. Fix on those lines is attached with this mail. > > Thanks to Dilip Kumar for helping me in narrowing down this particular > problem. We were not able to generate the exact test, but I think the above > theory is sufficient to prove that it can cause a problem as seen in the > original bug report.
I could be wrong, but I thought that the target list for an expression would always contain only Vars at this stage. Non-default tlists get injected at the end of scan/join planning. Am I wrong? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
