Thanks for taking a look.
On 2019/04/04 19:48, Michael Paquier wrote:
> 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?
OK, I've divided the patch that adds tests into its own.
> 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.
Done that way.
v2-0001_*, the test patch, can be applied to HEAD and PG 11 branches. Of
course, one would want to commit 0001 and 0002 together in PG 11, because
you'll see the ERROR in the output in patch 0001, which is same as the
reported error.
I've also modified 0001 so that it can be applied to PG 10, attached as
pg10-0001*.
Both HEAD and PG 10 don't need any code changes.
Thanks,
Amit
