pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Imai, Yoshikazu <imai.yoshikazu@jp.fujitsu.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: speeding up planning with partitions
Date: Mon, 28 Jan 2019 17:21:01 +0900
Message-ID: <c0cdadef-4110-ebb5-bbf7-7140c2fd2ae0@lab.ntt.co.jp> (raw )
In-Reply-To: <CAKJS1f-THx93QgN2x8zdb6JJsgV6ntfghyUq1NTz5UNJWCVNvw@mail.gmail.com >
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 >
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
view thread (265+ messages) latest in thread
Message-ID: <c0cdadef-4110-ebb5-bbf7-7140c2fd2ae0@lab.ntt.co.jp>
Permalink: ../c0cdadef-4110-ebb5-bbf7-7140c2fd2ae0@lab.ntt.co.jp/
Also on: postgresql.org/message-id/c0cdadef-4110-ebb5-bbf7-7140c2fd2ae0@lab.ntt.co.jp
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: Langote_Amit_f8@lab.ntt.co.jp, david.rowley@2ndquadrant.com, imai.yoshikazu@jp.fujitsu.com, alvherre@2ndquadrant.com
Subject: Re: speeding up planning with partitions
In-Reply-To: <c0cdadef-4110-ebb5-bbf7-7140c2fd2ae0@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox