1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
# Verify that default partition constraint is enforced correctly
# in light of partitions being added concurrently to its parent
setup {
drop table if exists tpart;
create table tpart(i int, j text) partition by range(i);
create table tpart_1(like tpart);
create table tpart_2(like tpart);
create table tpart_default (a int, j text, i int) partition by list (j);
create table tpart_default_default (a int, i int, b int, j text);
alter table tpart_default_default drop b;
alter table tpart_default attach partition tpart_default_default default;
alter table tpart_default drop a;
alter table tpart attach partition tpart_default default;
alter table tpart attach partition tpart_1 for values from(0) to (100);
insert into tpart_2 values (110,'xxx'), (120, 'yyy'), (150, 'zzz');
}
session s1
step s1b { begin; }
step s1a { alter table tpart attach partition tpart_2 for values from (100) to (200); }
step s1c { commit; }
session s2
step s2b { begin; }
step s2i { insert into tpart values (110,'xxx'), (120, 'yyy'), (150, 'zzz'); }
step s2i2 { insert into tpart_default (i, j) values (110, 'xxx'), (120, 'yyy'), (150, 'zzz'); }
step s2c { commit; }
step s2s { select tableoid::regclass, * from tpart; }
teardown { drop table tpart; }
# insert into tpart by s2 which routes to tpart_default due to not seeing
# concurrently added tpart_2 should fail, because the partition constraint
# of tpart_default would have changed due to tpart_2 having been added
permutation s1b s1a s2b s2i s1c s2c s2s
# similar to above, but now insert into sub-partitioned tpart_default
permutation s1b s1a s2b s2i2 s1c s2c s2s
# reverse: now the insert into tpart_default by s2 occurs first followed by
# attach in s1, which should fail when it scans the leaf default partition
# find the violating rows
permutation s1b s2b s2i s1a s2c s1c s2s
|
