Menu
▾
▴
Re: [Postgres-xc-developers] Query Planning bug ?
|
From: Tomonari K. <kat...@po...> - 2013-07-01 08:04:07
|
Hi Ashutosh and all,
Sorry for late response.
I made a patch for resolving the problem I mentioned before.
I thought the reason of this problem is parsing query twice.
because of this, the rtable is made from same Lists and become
cycliced List.
I fixed this problem with making former List empty.
I'm not sure this fix leads any anothre problems but
the problem query I mentioned before works fine.
This patch is against for "a074cac9b6b507e6d4b58c5004673f6cc65fcde1".
regards,
------------------
NTT Software Corporation
Tomonari Katsumata
(2013/06/17 18:53), Ashutosh Bapat wrote:
> Hi Tomonari,
> In which function have you taken this debug info? What is list1 and list2?
>
>
> On Mon, Jun 17, 2013 at 10:13 AM, Tomonari Katsumata <
> kat...@po...> wrote:
>
>> Hi Ashtosh,
>>
>> Sorry for slow response.
>>
>> I've watched the each lists at list_concat function.
>>
>> This function is called several times, but the lists before
>> last infinitely roop are like below.
>>
>> [list1]
>> (gdb) p *list1->head
>> $18 = {data = {ptr_value = 0x17030e8, int_value = 24129768,
>> oid_value = 24129768}, next = 0x170d418}
>> (gdb) p *list1->head->next
>> $19 = {data = {ptr_value = 0x17033d0, int_value = 24130512,
>> oid_value = 24130512}, next = 0x170fd40}
>> (gdb) p *list1->head->next->next
>> $20 = {data = {ptr_value = 0x170ae58, int_value = 24161880,
>> oid_value = 24161880}, next = 0x171e6c8}
>> (gdb) p *list1->head->next->next->next
>> $21 = {data = {ptr_value = 0x1702ca8, int_value = 24128680,
>> oid_value = 24128680}, next = 0x171ed28}
>> (gdb) p *list1->head->next->next->next->next
>> $22 = {data = {ptr_value = 0x170af68, int_value = 24162152,
>> oid_value = 24162152}, next = 0x171f3a0}
>> (gdb) p *list1->head->next->next->next->next->next
>> $23 = {data = {ptr_value = 0x170b0a8, int_value = 24162472,
>> oid_value = 24162472}, next = 0x170b7c0}
>> (gdb) p *list1->head->next->next->next->next->next->next
>> $24 = {data = {ptr_value = 0x17035f0, int_value = 24131056,
>> oid_value = 24131056}, next = 0x1720998}
>> ---- from ---
>> (gdb) p *list1->head->next->next->next->next->next->next->next
>> $25 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
>> oid_value = 24250808}, next = 0x1721190}
>> (gdb) p *list1->head->next->next->next->next->next->next->next->next
>> $26 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
>> oid_value = 24252848}, next = 0x1721988}
>> (gdb) p *list1->head->next->next->next->next->next->next->next->next->next
>> $27 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
>> oid_value = 24254888}, next = 0x1722018}
>> (gdb) p
>> *list1->head->next->next->next->next->next->next->next->next->next->next
>> $28 = {data = {ptr_value = 0x1722038, int_value = 24256568,
>> oid_value = 24256568}, next = 0x1722820}
>> (gdb) p
>>
>> *list1->head->next->next->next->next->next->next->next->next->next->next->next
>> $29 = {data = {ptr_value = 0x1722840, int_value = 24258624,
>> oid_value = 24258624}, next = 0x0}
>> ---- to ----
>>
>> [list2]
>> (gdb) p *list2->head
>> $31 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
>> oid_value = 24250808}, next = 0x1721190}
>> (gdb) p *list2->head->next
>> $32 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
>> oid_value = 24252848}, next = 0x1721988}
>> (gdb) p *list2->head->next->next
>> $33 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
>> oid_value = 24254888}, next = 0x1722018}
>> (gdb) p *list2->head->next->next->next
>> $34 = {data = {ptr_value = 0x1722038, int_value = 24256568,
>> oid_value = 24256568}, next = 0x1722820}
>> (gdb) p *list2->head->next->next->next->next
>> $35 = {data = {ptr_value = 0x1722840, int_value = 24258624,
>> oid_value = 24258624}, next = 0x0}
>> ----
>>
>> list1's last five elements are same with list2's all elements.
>> (in above example, between "from" and "to" in list1 equal all of list2)
>>
>> This is cause of infinitely roop, but I can not
>> watch deeper.
>> Because some values from gdb are optimized and un-displayed.
>> I tried compile with CFLAGS=O0, but I can't.
>>
>> What can I do more ?
>>
>> regards,
>> ------------------
>> NTT Software Corporation
>> Tomonari Katsumata
>>
>> (2013/06/12 21:04), Ashutosh Bapat wrote:
>> > Hi Tomonari,
>> > Can you please check the list's sanity before calling pgxc_collect_RTE()
>> > and at every point in the minions of this function. My primary suspect
>> is
>> > the line pgxcplan.c:3094. We should copy the list before
>> concatenating it.
>> >
>> >
>> > On Wed, Jun 12, 2013 at 2:26 PM, Tomonari Katsumata <
>> > kat...@po...> wrote:
>> >
>> >> Hi Ashutosh,
>> >>
>> >> Thank you for the response.
>> >>
>> >> (2013/06/12 14:43), Ashutosh Bapat wrote:
>> >> >> Hi,
>> >> >> >
>> >> >> > I've investigated this problem(BUG:3614369).
>> >> >> >
>> >> >> > I caught the cause of it, but I can not
>> >> >> > find where to fix.
>> >> >> >
>> >> >> > The problem occurs when "pgxc_collect_RTE_walker" is called
>> >> infinitely.
>> >> >> > It seems that rtable(List of RangeTable) become cyclic List.
>> >> >> > I'm not sure where the List is made.
>> >> >> >
>> >> >> >
>> >> > I guess, we are talking about EXECUTE DIRECT statement that you have
>> >> > mentioned earlier.
>> >>
>> >> Yes, that's right.
>> >> I'm talking about EXECUTE DIRECT statement like below.
>> >> ---
>> >> EXECUTE DIRECT ON (data1) $$
>> >> SELECT
>> >> count(*)
>> >> FROM
>> >> (SELECT * FROM pg_locks l LEFT JOIN
>> >> (SELECT * FROM pg_stat_activity) s ON l.database = s.datid) a
>> >> $$
>> >> ---
>> >>
>> >> > The function pgxc_collect_RTE_walker() is a recursive
>> >> > function. The condition to end the recursion is if the given node is
>> >> NULL.
>> >> > We have to look at if that condition is met and if not why.
>> >> >
>> >> I investigated it deeper, and I noticed that
>> >> the infinitely loop happens at the function "range_table_walker()".
>> >>
>> >> Please see below trace.
>> >> ===========================
>> >> Breakpoint 1, range_table_walker (rtable=0x15e7968, walker=0x612c70
>> >> <pgxc_collect_RTE_walker>, context=0x7fffd2de31c0,
>> >> flags=0) at nodeFuncs.c:1908
>> >> 1908 in nodeFuncs.c
>> >>
>> >> (gdb) p *rtable
>> >> $10 = {type = T_List, length = 5, head = 0x15e7998, tail = 0x15e9820}
>> >> (gdb) p *rtable->head
>> >> $11 = {data = {ptr_value = 0x15e79b8, int_value = 22968760, oid_value =
>> >> 22968760}, next = 0x15e8190}
>> >> (gdb) p *rtable->head->next
>> >> $12 = {data = {ptr_value = 0x15e81b0, int_value = 22970800, oid_value =
>> >> 22970800}, next = 0x15e8988}
>> >> (gdb) p *rtable->head->next->next
>> >> $13 = {data = {ptr_value = 0x15e89a8, int_value = 22972840, oid_value =
>> >> 22972840}, next = 0x15e9018}
>> >> (gdb) p *rtable->head->next->next->next
>> >> $14 = {data = {ptr_value = 0x15e9038, int_value = 22974520, oid_value =
>> >> 22974520}, next = 0x15e9820}
>> >> (gdb) p *rtable->head->next->next->next->next
>> >> $15 = {data = {ptr_value = 0x15e9840, int_value = 22976576, oid_value =
>> >> 22976576}, next = 0x15e7998}
>> >> ===========================
>> >>
>> >> The line which starts with "$15" has 0x15e7998 as its next data.
>> >> But it is the head pointer(see the line which starts with $10).
>> >>
>> >> And in range_table_walker(), the function is called recursively.
>> >> --------
>> >> ...
>> >> if (!(flags & QTW_IGNORE_RANGE_TABLE))
>> >> {
>> >> if (range_table_walker(query->rtable, walker, context,
>> >> flags))
>> >> return true;
>> >> }
>> >> ...
>> >> --------
>> >>
>> >> We should make rtable right or deal with "flags" properly.
>> >> But I can't find where to do it...
>> >>
>> >> What do you think ?
>> >>
>> >> regards,
>> >> ---------
>> >> NTT Software Corporation
>> >> Tomonari Katsumata
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> ------------------------------------------------------------------------------
>> >> This SF.net email is sponsored by Windows:
>> >>
>> >> Build for Windows Store.
>> >>
>> >> http://p.sf.net/sfu/windows-dev2dev
>> >> _______________________________________________
>> >> Postgres-xc-developers mailing list
>> >> Pos...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >>
>> >
>> >
>> >
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>
>
|
