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"
|
