Fix segfault on execution of multilevel correlated queries.

[InnerLife0]

Execution of multilevel correlated queries with high level of nesting can cause segfault(when using array_agg, json_agg) or can provide wrong results (when using classic aggs like sum()). Due to some GP limitations, correlated subqueries with skip-level correlations are not supported. Additional check condition is provided to prevent such queries from planning. QueryHasDistributedRelation function, used by this check, doesn't recurse over subplans and may return wrong results for distributed RTE_RELATION entries hided by RTE_SUBQUERY entries.
Commit fixes such behavior by adding optional recursion to QueryHasDistributedRelation function. Additional regression test is included. Additional information can be found at issue #12054.

[InnerLife0]

Still waiting pivotal for some GP limitations explanation.

[InnerLife0]

Got explanation and PR pre-approval from pivotal.

[InnerLife0]

Cherry picked additional changes proposed by pivotal developer.

[darthunix]

If we treat this PR as a hot fix, then LGTM. But I agree with @guofengrichard - we should think how to build a correct plan for correlated subqueries with SubPlans instead of InitPlans (surely, it is a separate task). @Stolb27 what do you think?

[Stolb27]

what do you think?

@darthunix, I've tried to reproduce the mentioned case on 6X_STABLE and got the next results.

test=# set optimizer = off;                                                                                                                                                                     
SET
test=# explain (costs off) select * from a where a.i in (select j from b where b.j = (select count(*) from c where c.i = a.i));                                                                 
ERROR:  correlated subquery with skip-level correlations is not supported
test=# set optimizer=on;
SET
test=# explain (costs off) select * from a where a.i in (select j from b where b.j = (select count(*) from c where c.i = a.i));
                                 QUERY PLAN                                 
----------------------------------------------------------------------------
 Result
   Filter: (SubPlan 2)
   ->  Gather Motion 3:1  (slice1; segments: 3)
         ->  Seq Scan on a
   SubPlan 2  (slice0)
     ->  Result
           Filter: (b.j = (SubPlan 1))
           ->  Materialize
                 ->  Gather Motion 3:1  (slice2; segments: 3)
                       ->  Seq Scan on b
           SubPlan 1  (slice0)
             ->  Aggregate
                   ->  Result
                         Filter: (c.i = a.i)
                         ->  Materialize
                               ->  Gather Motion 3:1  (slice3; segments: 3)
                                     ->  Seq Scan on c
 Optimizer: Pivotal Optimizer (GPORCA)
(18 rows)

There are correlated SubPlans only. Can you explain for me mentioned problem?

[darthunix]

@Stolb27 it is legal to use nested correlated SubPlans - we have only a problem with InitPlans. It is good that Orca can build a correct plan with SubPlans instead of InitPlans (but I have no idea, does ORCA always use SubPlans instead of InitPlans where needed). Current PR fixes only Postgres optimizer.