Re: Asymmetric partition-wise JOIN - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: Asymmetric partition-wise JOIN
Date
Msg-id CAOP8fzaDAP_6dR0VbCQrc5smcdzvwx5vEafs6bNhEesP0VP2KA@mail.gmail.com
Whole thread Raw
In response to Re: Asymmetric partition-wise JOIN  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Asymmetric partition-wise JOIN  (David Steele <david@pgmasters.net>)
Re: Asymmetric partition-wise JOIN  (Daniel Gustafsson <daniel@yesql.se>)
Re: Asymmetric partition-wise JOIN  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
List pgsql-hackers
Hello,

This crash was reproduced on our environment also.
It looks to me adjust_child_relids_multilevel() didn't expect a case
when supplied 'relids'
(partially) indicate normal and non-partitioned relation.
It tries to build a new 'parent_relids' that is a set of
appinfo->parent_relid related to the
supplied 'child_relids'. However, bits in child_relids that indicate
normal relations are
unintentionally dropped here. Then, adjust_child_relids_multilevel()
goes to an infinite
recursion until stack limitation.

The attached v2 fixed the problem, and regression test finished correctly.

Best regards,

2019年12月1日(日) 12:24 Michael Paquier <michael@paquier.xyz>:
>
> On Sat, Aug 24, 2019 at 05:33:01PM +0900, Kohei KaiGai wrote:
> > On the other hands, it eventually consumes almost equivalent amount
> > of memory to load the inner relations, if no leafs are pruned, and if we
> > could extend the Hash-node to share the hash-table with sibling
> > join-nodess.
>
> The patch crashes when running the regression tests, per the report of
> the automatic patch tester.  Could you look at that?  I have moved the
> patch to nexf CF, waiting on author.
> --
> Michael



--
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai@heterodb.com>

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Duplicate Workers entries in some EXPLAIN plans
Next
From: ROS Didier
Date:
Subject: RE: problem with read-only user