ADBDEV-2885: Postgres planner produces bogus plan for query to replicated table with SIRV function

[RekGRpth]

Query with subplan containing volatile functions on distributed replicated tables does not make motion gather. This produces wrong plan and leads to segfault.
Steps to reproduce this problem:

create table t (i int) distributed replicated;
insert into t select 1;
create function f(i int) returns int language sql security definer as $$ select i; $$;
select (select f(i) from t); -- <-- segfault here!!!
select (select f(i) from t group by f(i)); -- <-- segfault here!!!
select (select i from t group by i having f(i) > 0); -- <-- segfault here!!!

Wrong plans:

explain (costs off, verbose) SELECT (select f(i) from t);
             QUERY PLAN              
-------------------------------------
 Result
   Output: $0
   InitPlan 1 (returns $0)
     ->  Seq Scan on public.t
           Output: f(i)
 Optimizer: Postgres query optimizer
(6 rows)
explain (costs off, verbose) SELECT (select f(i) from t group by f(i));
             QUERY PLAN              
-------------------------------------
 Result
   Output: $0
   InitPlan 1 (returns $0)
     ->  HashAggregate
           Output: (f(i))
           Group Key: f(t.i)
           ->  Seq Scan on public.t
                 Output: i, f(i)
 Optimizer: Postgres query optimizer
(9 rows)
explain (costs off, verbose) SELECT (select i from t group by i having f(i) > 0);
             QUERY PLAN              
-------------------------------------
 Result
   Output: $0
   InitPlan 1 (returns $0)
     ->  HashAggregate
           Output: i
           Group Key: t.i
           Filter: (f(t.i) > 0)
           ->  Seq Scan on public.t
                 Output: i
 Optimizer: Postgres query optimizer
(10 rows)

Solving problem includes make explicit motion gather for such subplan and only for it.
Right plans:

explain (costs off, verbose) SELECT (select f(i) from t);
                    QUERY PLAN                    
--------------------------------------------------
 Result
   Output: $0
   InitPlan 1 (returns $0)  (slice2)
     ->  Gather Motion 1:1  (slice1; segments: 1)
           Output: (f(i))
           ->  Seq Scan on public.t
                 Output: f(i)
 Optimizer: Postgres query optimizer
(8 rows)
explain (costs off, verbose) SELECT (select f(i) from t group by f(i));
                    QUERY PLAN                    
--------------------------------------------------
 Result
   Output: $0
   InitPlan 1 (returns $0)  (slice2)
     ->  Gather Motion 1:1  (slice1; segments: 1)
           Output: (f(i))
           ->  HashAggregate
                 Output: (f(i))
                 Group Key: f(t.i)
                 ->  Seq Scan on public.t
                       Output: i, f(i)
 Optimizer: Postgres query optimizer
(11 rows)
explain (costs off, verbose) SELECT (select i from t group by i having f(i) > 0);
                    QUERY PLAN                    
--------------------------------------------------
 Result
   Output: $0
   InitPlan 1 (returns $0)  (slice2)
     ->  Gather Motion 1:1  (slice1; segments: 1)
           Output: i
           ->  HashAggregate
                 Output: i
                 Group Key: t.i
                 Filter: (f(t.i) > 0)
                 ->  Seq Scan on public.t
                       Output: i
 Optimizer: Postgres query optimizer
(12 rows)

[Stolb27]

Please describe the meaning of both code lines in the commit and PR description.

[RekGRpth]

for query (on distributed replicated tables) containing volatile functions consider adjust plan flow

[Stolb27]

Please provide test description.
It's not recommended to limit test execution by some planner (except cases when it leads to creation new copy of out file, or reproduction steps uses fault injector and freezes on the different optimizer).

[RekGRpth]

done

[Stolb27]

You may use costs off to decrease patch footprint in this case. More, I think that explain analyze is enough (valid plan + SIGSEGV absence).

[RekGRpth]

done

[Stolb27]

The next queries are planned incorrect with current version of patch (SIGSEGV without patch):

SELECT (select f(i) from t group by f(i));
SELECT (select i from t group by i having f(i) > 0);

In my opinion, you are trying to solve exact problem, but the problem is wider. Replicated table implementation in gpdb should be rewritten from scratch. GPDB refuses to apply motion for data outside the coordinator.

The base branch was changed.