Re: BUG #14657: Server process segmentation fault in v10, May 10th dev snapshot

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, sveinn(dot)sveinsson(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #14657: Server process segmentation fault in v10, May 10th dev snapshot
Date: 2017-05-18 01:53:15
Message-ID: 6b2fb5ff-40e1-fda3-3ce5-6723e9e5df61@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2017/05/18 10:49, Amit Langote wrote:
> On 2017/05/18 2:14, Dilip Kumar wrote:
>> On Wed, May 17, 2017 at 7:41 PM, <sveinn(dot)sveinsson(at)gmail(dot)com> wrote:
>>> (gdb) bt
>>> #0 0x000000000061ab1b in list_nth ()
>>> #1 0x00000000005e4081 in ExecLockNonLeafAppendTables ()
>>> #2 0x00000000005f4d52 in ExecInitMergeAppend ()
>>> #3 0x00000000005e0365 in ExecInitNode ()
>>> #4 0x00000000005f35a7 in ExecInitLimit ()
>>> #5 0x00000000005e00f3 in ExecInitNode ()
>>> #6 0x00000000005dd207 in standard_ExecutorStart ()
>>> #7 0x00000000006f96d2 in PortalStart ()
>>> #8 0x00000000006f5c7f in exec_simple_query ()
>>> #9 0x00000000006f6fac in PostgresMain ()
>>> #10 0x0000000000475cdc in ServerLoop ()
>>> #11 0x0000000000692ffa in PostmasterMain ()
>>> #12 0x0000000000476600 in main ()
>
> Thanks for the test case Sveinn and thanks Dilip for analyzing.
>
>> Seems like the issue is that the plans under multiple subroots are
>> pointing to the same partitioned_rels.
>
> That's correct.
>
>> If I am not getting it wrong "set_plan_refs(PlannerInfo *root, Plan
>> *plan, int rtoffset)" the rtoffset is specific to the subroot. Now,
>> problem is that set_plan_refs called for different subroot is updating
>> the same partition_rel info and make this value completely wrong which
>> will ultimately make ExecLockNonLeafAppendTables to access the out of
>> bound "rte" index.
>
> Yes.
>
>> set_plan_refs
>> {
>> [clipped]
>> case T_MergeAppend:
>> {
>> [clipped]
>>
>> foreach(l, splan->partitioned_rels)
>> {
>> lfirst_int(l) += rtoffset;
>>
>>
>> I think the solution should be that create_merge_append_path make the
>> copy of partitioned_rels list?
>
> Yes, partitioned_rels should be copied.
>
>> Attached patch fixes the problem but I am not completely sure about the fix.
>
> Thanks for creating the patch, although I think a better fix would be to
> make get_partitioned_child_rels() do the list_copy. That way, any other
> users of partitioned_rels will not suffer the same issue. Attached patch
> implements that, along with a regression test.
>
> Added to the open items.

Oops, forgot to cc -hackers. Patch attached again.

Thanks,
Amit

Attachment Content-Type Size
0001-Fix-crash-when-partitioned-table-Append-referenced-i.patch text/x-diff 3.6 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dilip Kumar 2017-05-18 03:26:40 Re: BUG #14657: Server process segmentation fault in v10, May 10th dev snapshot
Previous Message Amit Langote 2017-05-18 01:49:38 Re: BUG #14657: Server process segmentation fault in v10, May 10th dev snapshot

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-05-18 02:01:57 Re: [Proposal] Allow users to specify multiple tables in VACUUM commands
Previous Message Ashutosh Bapat 2017-05-18 01:52:02 Re: postgres_fdw aggregation pushdown has collation change in 10beta.