Re: Oddity in tuple routing for foreign partitions

(2018/04/26 20:06), Kyotaro HORIGUCHI wrote:
> It seems almost fine for me, but just one point..
>
> At Thu, 26 Apr 2018 17:36:44 +0900, Etsuro Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in<5AE18F9C(dot)6080805(at)lab(dot)ntt(dot)co(dot)jp>
>> (2018/04/26 15:35), Amit Langote wrote:
>>> On 2018/04/26 12:43, Etsuro Fujita wrote:
>>> + resultRelation == plan->nominalRelation)
>>> + resultRelation = mtstate->resultRelInfo[0].ri_RangeTableIndex;
>>> + }
>>
>> Seems like a better change than mine; because this simplifies the
>> logic.
>
> Please rewrite it to use not array reference, but pointer
> reference if one mtstate logically holds just one resultRelInfo.

Maybe I don't understand your words correctky, but in that UPDATE case,
I think that mtstate can have multiple ResultRelInfo.

>>>>>>> So, attached are two patches.
>>>>>>>
>>>>>>> 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to
>>>>>>> InitResultRelInfo
>>>>>>>
>>>>>>> 2. v5 of the patch to fix the bug of foreign partitions
>>>>>>>
>>>>>>> Thoughts?
>>>>
>>>> Actually, I also thought the former when creating the patch, but I
>>>> left
>>>> that as-is because I'm not sure that would be really safe;
>>>> ExecConstraints
>>>> looks at the RT index via GetInsertedColumns/GetUpdatedColumns, so
>>>> what I
>>>> thought was: that might cause unexpected behavior.
>>>
>>> OK, I have to agree here that we better leave 1 to be looked at later.
>>>
>>> After this change, GetInsertedColumns/GetUpdatedColumns will start
>>> returning a different set of columns in some cases than it does now.
>>> Currently, it *always* returns a set containing root table's attribute
>>> numbers, even for UPDATE. But with this change, for UPDATE, it will
>>> start
>>> returning the set containing the first subplan target rel's attribute
>>> numbers, which could be any partition with arbitrarily different
>>> attribute
>>> numbers.
>>>
>>>> Anyway, I think that
>>>> the former is more like an improvement rather than a fix, so it would
>>>> be
>>>> better to leave that for another patch for PG12?
>>>
>>> I agree, so I'm dropping the patch for 1.
>>
>> OK, let's focus on #2!
>>
>>> See attached an updated version with changes as described above.
>>
>> Looks good to me. Thanks for the updated version!
>
> Agreed on all points above.

Thanks for reviewing!

Best regards,
Etsuro Fujita