On Wed, Oct 4, 2017 at 12:55 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Oct 4, 2017 at 3:40 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Oct 3, 2017 at 7:33 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> Having said all that, I think that this patch only wants to handle the >> subset of cases (2) and (4) where the relevant InitPlan is attached >> ABOVE the Gather node -- which seems very reasonable, because >> evaluating an InitPlan at a level of the plan tree above the level at >> which it is defined sounds like it might be complex. But I still >> don't quite see why we need these tests. I mean, if we only allow >> Param references from a set of safe parameter IDs, and the safe >> parameter IDs include only those IDs that can be generated in a >> worker, then won't other InitPlans in the workers anyway be ruled out? > > It doesn't happen always. There are cases when the part of required > conditions are pushed one query level below, so when we check during > max_parallel_hazard_walker, they look safe, but actually, they are > not. I will try to explain by example: > > postgres=# explain (costs off, verbose) select * from t1 where t1.i in > ( select 1 + (select max(j) from t3));
If you want to reproduce this case, then you can use the script posted by Kuntal up thread [1]. [1] - https://www.postgresql.org/message-id/CAGz5QC%2BuHOq78GCika3fbgRyN5zgiDR9Dd1Th5kENF%2BUpnPomQ%40mail.gmail.com -- 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