gpdb
gpdb copied to clipboard
Fix INSERT INTO replicated table SELECT FROM another replicated with sequence generation
The last query from the series
set optimizer=off;
create table t_replicate_dst(id serial, i integer) distributed replicated;
create table t_replicate_src(i integer) distributed replicated;
insert into t_replicate_src select i from generate_series(1, 5) i;
insert into t_replicate_dst (i) select i from t_replicate_src;
select distinct id from gp_dist_random(t_replicate_dst);
returned 15 lines (not 5) on cluster with 3 segments. The plan of the second insert was:
Insert on t_replicate_dst
-> Seq Scan on t_replicate_src
The error is not reproduced on master, because when volatile functions are detected in the query at the stage of adding the Insert node, the Broadcast Motion node will be added. The plan on master is:
Insert on t_replicate_dst
-> Broadcast Motion 1:3 (slice1; segments: 1)
-> Seq Scan on t_replicate_src
After adding a check for the absence of volatile functions to the condition for refusing to insert the Broadcast Motion node, the query plan became the same as on master.
Thanks for your contribution! I will look into the PR this week.
My colleagues and I discovered that there is another similar problem when using replicated table and volatile functions.
Steps to reproduce segfault:
set optimizer= off;
drop table if exists t;
create table t (i int) distributed replicated;
insert into t select 1;
create or replace function f(i int) returns int language sql security definer as $$ select i; $$;
explain SELECT (select f(i) from t);
explain analyze SELECT (select f(i) from t);
We are currently working on a patch that should fix both problems. But we don't know yet whether it will be possible to fix both problems with one patch.
@andr-sokolov do you have update on the new problem/fix you were working on?
@ashwinstar , I don't have a new patch yet. We are working on it here https://github.com/arenadata/gpdb/pull/383
OK. Let's push this first and wait for new patches. Thanks a lot!