On Thu, Apr 04, 2019 at 07:31:09PM +0900, Amit Langote wrote:
> The problem seems to be present only in PG 11; not in PG 10 and HEAD, as
> Michael already said.
>
> It seems to have been introduced by 34295b87f in PG 11, wherein the
> decision of when to add a tuple to an intermediate parent's dedicated
> tuple routing slot is mistakenly getting mixed with the decision of
> whether tuple conversion is required between the parent of the previous
> level and the current parent. We didn't catch that error back then,
> because we only tried up to 2 levels of partitioning, whereas the test
> case presented here uses 3 levels of partitioning. In the reported test
> case, the 1st level needs tuple conversion (between partitioned and
> partitioned_2), but the next level does not (between partitioned_2 and
> partitioned_2_1), so the slot used when routing through partitioned_2_1 to
> the last level doesn't contain a tuple to extract the partition key from,
> hence the error.
Perhaps it would make sense to have this test case on HEAD as well?
It seems to me that there is little point in having a completely new
set of relations to test this issue knowing that multi-level
partitioning is already tested in the same file. Why not extending
the part close to "more tests for certain multi-level partitioning
scenarios" in insert.sql with a mlparted111 or such a thing? This
way, we have a three-layer partitioning and the error can be equally
triggered.
--
Michael