Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, amdmi3(at)amdmi3(dot)ru, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Jakub Janeček <jakub(dot)janecek(at)comgate(dot)cz>
Subject: Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression)
Date: 2019-02-09 15:09:57
Message-ID: 6147.1549724997@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-02-09 09:34:41 -0500, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> ... Given that, I think it's ok
>>> to not explicitly shutdown the expr context.

>> Uh, what?

> Well, you explicitly removed the surrounding reasoning. What's the issue
> you see here? The generated expression cannot contain anything that uses
> shutdown callbacks

Even if that happens to be true today, it certainly looks like a booby
trap primed and ready to bite somebody in the future. An ExprContext
that fails to provide one of the basic services of an ExprContext ---
indeed, the *only* basic service of an ExprContext, since whatever else
it does is just a memory context feature --- doesn't sound like a great
plan to me.

What is it you're actually hoping to do by removing this guarantee?
(I apologize for not having been paying attention to this thread,
but I do have finite bandwidth.)

>> This doesn't really seem like the kind of patch to push on a release
>> weekend. At this point you can't even be confident of getting a readout
>> from every active buildfarm member.

> Yea, I'd hoped to push this earlier, but unfortune family issues +
> related travel + work travel prevented me from getting to this
> earlier. The memory leak is significant, the patch hasn't materially
> changed in the two weeks since it has been posted, and there's nothing
> operating system / architecture related, which I think makes this
> acceptable.

I'm thinking more of the valgrind and clobber_cache_always members,
which are pretty slow by definition.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2019-02-09 15:30:47 Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression)
Previous Message Andres Freund 2019-02-09 15:00:28 Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression)