Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning
Date: 2023-09-21 01:06:58
Message-ID: CA+HiwqHJ+Su3XwT-zeBvyO+8=4ms19oZNBPtqb8P5a-z-fH3fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 20, 2023 at 10:24 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> On Wed, Sep 20, 2023 at 5:24 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > Just one comment on 0003:
> >
> > + /*
> > + * Dummy SpecialJoinInfos do not have any translated fields and hence have
> > + * nothing to free.
> > + */
> > + if (child_sjinfo->jointype == JOIN_INNER)
> > + return;
> >
> > Should this instead be Assert(child_sjinfo->jointype != JOIN_INNER)?
>
> try_partitionwise_join() calls free_child_sjinfo_members()
> unconditionally i.e. it will be called even SpecialJoinInfos of INNER
> join. Above condition filters those out early. In fact if we convert
> into an Assert, in a production build the rest of the code will free
> Relids which are referenced somewhere else causing dangling pointers.

You're right. I hadn't realized that the parent SpecialJoinInfo
passed to try_partitionwise_join() might itself be a dummy. I guess I
should've read the whole thing before commenting.

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryoga Yoshida 2023-09-21 01:44:49 Bug fix in vacuumdb --buffer-usage-limit xxx -Z
Previous Message Thomas Munro 2023-09-21 00:47:35 Re: LLVM 16 (opaque pointers)