On 2020-Sep-04, Amit Langote wrote:
Hello
> FWIW, I still prefer "minimally valid ResultRelInfo" to "fake
> ResultRelInfo", because those aren't really fake, are they? They are
> as valid as any other ResultRelInfo as far I can see. I said
> "minimally valid" because a fully-valid partition ResultRelInfo is one
> made by ExecInitPartitionInfo(), which I avoided to use here thinking
> that would be overkill.
Well, they are fake in that the ri_RangeTableIndex they carry is bogus,
which means that ExecBuildSlotValueDescription will misbehave if the
partitioned default partition has a different column order than its
parent. That can be evidenced by changing the setup block in the
isolation test as in the attached; and you'll get an undesirable error
like this:
2020-09-07 19:00:49.513 -03 [12981] ERROR: attribute 2 of type record has
wrong type
2020-09-07 19:00:49.513 -03 [12981] DETAIL: Table has type text, but query
expects integer.
2020-09-07 19:00:49.513 -03 [12981] STATEMENT: insert into attach_tab values
(110, 'eleven and five twenties');
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
# 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"
