From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Andres Freund <andres@anarazel.de>, lauri.laanmets@eesti.ee,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Memory leak on subquery as scalar operand
In-reply-to: 
 <CAApHDvqn55aqReCSAd9tpf06JV0sx=DYON+djSv1BqkJZ+NH_Q@mail.gmail.com>
References: 
 <CAPH-tTxLf44s3CvUUtQpkDr1D8Hxqc2NGDzGXS1ODsfiJ6WSqA@mail.gmail.com>
 <CAApHDvrSbQkPUacnaonQzw1efFJM6HE5we-i9VVogBfEKGCCiA@mail.gmail.com>
 <1046179.1667263449@sss.pgh.pa.us>
 <CAApHDvpL=3-61Lsfd9P5vuf48sJgKYP1qUULDEoKcAsEJpZA7g@mail.gmail.com>
 <1073512.1667275802@sss.pgh.pa.us>
 <CAApHDvqn55aqReCSAd9tpf06JV0sx=DYON+djSv1BqkJZ+NH_Q@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Tue, 01 Nov 2022 17:26:16 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1084047.1667278336.1@sss.pgh.pa.us>
Date: Tue, 01 Nov 2022 00:52:16 -0400
Message-ID: <1084048.1667278336@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1084048.1667278336%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> The single subquery version also crashes for me, so perhaps it's just
> the amount of memory that's being used and when the OOM killer is
> triggering.
> It crashes even when I set jit_inline_above_cost and
> jit_optimize_above_cost above the query's cost.

Hmm, maybe we're not seeing the same thing?  For me, the behavior
seems similar to what the OP reported: there's a per-query leakage
but it's less than 100kB per query.  It'd take more than a handful
of repetitions to get to an OOM failure.  This is with LLVM 13.0.1
on RHEL 8.6.

Also, as far as I can see there is no leak with the single-subquery
version.  The process's reported VIRT consumption bounces around a
fair amount, but it doesn't go above 300MB, even after ~10min in
a tight plpgsql DO loop.  VIRT bounces around a lot with the
two-subquery version too, actually, but there does seem to be a
general uptrend there.  I did not have the patience to wait for
actual OOM; it looked like it'd take a good long while, tens
of minutes at least.

If the behavior varies across LLVM versions, as is now seeming
a bit likely, it might be their bug not ours.

			regards, tom lane