Subject: Re: speeding up planning with partitions
References: <20181107033207.cdisp33ryrgeidef@alvherre.pgsql>
 <f74d2f85-a9c3-f82d-188a-fcfe77911e78@lab.ntt.co.jp>
 <3be67028-a00a-502c-199a-da00eec8fb6e@lab.ntt.co.jp>
 <CAKJS1f8g9_BzE678BLBm-eoMMEYUUXhDABSpqtAHRUUTrm_vFA@mail.gmail.com>
 <a22f24d1-5e20-f352-f402-3101cb1213bd@lab.ntt.co.jp>
 <73596f90-023c-c358-be9a-3c21bffcb15d@lab.ntt.co.jp>
 <0F97FA9ABBDBE54F91744A9B37151A5122E7B1@g01jpexmbkw24>
 <08a6775f-7c88-81a8-8c2c-984d171b6db9@lab.ntt.co.jp>
 <0F97FA9ABBDBE54F91744A9B37151A51232FF7@g01jpexmbkw24>
 <0F97FA9ABBDBE54F91744A9B37151A5124C0A0@g01jpexmbkw24>
 <580ddb99-cd31-096d-d485-fc309d274498@lab.ntt.co.jp>
 <55bd88c6-f311-2791-0a36-11c693c69753@lab.ntt.co.jp>
 <e35fb0c3-fdeb-3db6-4d2a-614e89b3d17c@lab.ntt.co.jp>
 <CAKJS1f-3GLjDB0_-wvE0Zmzuk0655tVu3O-CcLEfocuPRZHxPQ@mail.gmail.com>
 <cf0cf28b-66ee-568c-c9f5-5577ac968959@lab.ntt.co.jp>
 <CAKJS1f-THx93QgN2x8zdb6JJsgV6ntfghyUq1NTz5UNJWCVNvw@mail.gmail.com>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <c0cdadef-4110-ebb5-bbf7-7140c2fd2ae0@lab.ntt.co.jp>
Date: Mon, 28 Jan 2019 17:21:01 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CAKJS1f-THx93QgN2x8zdb6JJsgV6ntfghyUq1NTz5UNJWCVNvw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: "Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

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