Re: speeding up planning with partitions

Hi David,

On 2019/01/28 13:18, David Rowley wrote:
> On Sat, 12 Jan 2019 at 02:00, Amit Langote wrote:
>> On 2019/01/09 9:09, David Rowley wrote:
>>> postgres=# update parent set c = c where a = 333;
>>> server closed the connection unexpectedly
>>>         This probably means the server terminated abnormally
>>>         before or while processing the request.
>>>
>>> I didn't look into what's causing the crash.
>>
>> I tried your example, but it didn't crash for me:
>>
>> explain update parent set c = c where a = 333;
>>                      QUERY PLAN
>> ────────────────────────────────────────────────────
>>  Update on parent  (cost=0.00..0.00 rows=0 width=0)
>>    ->  Result  (cost=0.00..0.00 rows=0 width=54)
>>          One-Time Filter: false
>> (3 rows)
> 
> I had a closer look. The crash is due to
> set_inherit_target_rel_sizes() forgetting to set has_live_children to
> false. This results in the relation not properly being set to a dummy
> rel and the code then making a modify table node without any subnodes.
> That crashes due to getTargetResultRelInfo() returning NULL due to
> rootResultRelInfo and resultRelInfo both being NULL.

Oops, you're right.

> The attached fixes it. If you were not seeing the crash then
> has_live_children must have been zero/false by chance during your
> test.

Thanks for the fix, I'll incorporate it in the next version I'll post by
tomorrow.

Regards,
Amit