Subject: Re: BUG #14657: Server process segmentation fault in v10, May
 10th dev snapshot
References: <20170517141151.1435.79890@wrigleys.postgresql.org>
 <CAFiTN-uKBPY6cUVnea-OKbX=GpHj68jBqpZtTYdYEc_72UX+cQ@mail.gmail.com>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <e261ebf9-e916-8554-5e72-6e9348fd78fc@lab.ntt.co.jp>
Date: Thu, 18 May 2017 10:49:38 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
 <CAFiTN-uKBPY6cUVnea-OKbX=GpHj68jBqpZtTYdYEc_72UX+cQ@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------F017FFF9C09FAD2C4C326EB8"
To: Dilip Kumar <dilipbalaut@gmail.com>, sveinn.sveinsson@gmail.com
Cc: pgsql-bugs@postgresql.org
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

This is a multi-part message in MIME format.
--------------F017FFF9C09FAD2C4C326EB8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 2017/05/18 2:14, Dilip Kumar wrote:
> On Wed, May 17, 2017 at 7:41 PM,  <sveinn.sveinsson@gmail.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.

Thanks,
Amit

--------------F017FFF9C09FAD2C4C326EB8
Content-Type: text/x-diff;
 name="0001-Fix-crash-when-partitioned-table-Append-referenced-i.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0001-Fix-crash-when-partitioned-table-Append-referenced-i.pa";
 filename*1="tch"