# Verify that default partition constraint is enforced correctly
# in light of partitions being added concurrently to its parent
setup {
  drop table if exists attach_tab;
  create table attach_tab (i int, j text) partition by range (i);
  create table attach_tab_1 partition of attach_tab for values from (0) to (100);
  create table attach_tab_default (j text, i int) partition by range (i);
  alter table attach_tab attach partition attach_tab_default default;
  create table attach_tab_default_1 partition of attach_tab_default for values from (110) to (120);
  create table attach_tab_2 (like attach_tab);
  insert into attach_tab_2 values (111, 'ONE HUNDRED AND ELEVENTH BIRTHDAY');
}

session "s1"
step "s1b"	{ begin; }
step "s1a"	{ alter table attach_tab attach partition attach_tab_2 for values from (100) to (200); }
step "s1c"	{ commit; }

session "s2"
step "s2b"	{ begin; }
step "s2i"	{ insert into attach_tab values (111, 'eleven and five twenties'); }
step "s2c"	{ commit; }

teardown	{ drop table if exists attach_tab, attach_tab_1, attach_tab_2; }

# insert into attach_tab by s2 which routes to attach_tab_default due to not seeing
# concurrently added attach_tab_2 should fail, because the partition constraint
# of attach_tab_default would have changed due to attach_tab_2 having been added
permutation "s1b" "s1a" "s2b" "s2i" "s1c" "s2c"

# reverse: now the insert into attach_tab_default by s2 occurs first followed by
# attach in s1, which should fail when it scans the default partitions to
# find the violating rows
permutation "s1b" "s2b" "s2i" "s1a" "s2c" "s1c"