Re: BUG #15733: An insert destined at partition created after a column has been dropped from the parent table fails

Hi Petr, Michael,

On 2019/04/04 10:35, Michael Paquier wrote:
> On Wed, Apr 03, 2019 at 06:22:34PM +0000, PG Bug reporting form wrote:
>> 6. FAIL: Insert the row which would land at partitioned_2_1_1:
>>
>> insert into partitioned values(2,2,1, 1,1);
>>
>> ERROR: cannot extract attribute from empty tuple slot SQL state: XX000

Thanks for the report.

> Indeed. I can see that for v11 but not for HEAD. Let's keep track of
> that. (Not looking at that now though)

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.

Attached patch fixes this.

Thanks,
Amit