Re: Memory leak on subquery as scalar operand - Mailing list pgsql-bugs

From David Rowley
Subject Re: Memory leak on subquery as scalar operand
Date
Msg-id CAApHDvqn55aqReCSAd9tpf06JV0sx=DYON+djSv1BqkJZ+NH_Q@mail.gmail.com
Whole thread Raw
In response to Re: Memory leak on subquery as scalar operand  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Memory leak on subquery as scalar operand
List pgsql-bugs
On Tue, 1 Nov 2022 at 17:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Maybe the different "inlining" choice makes a difference?

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.

postgres=# set jit_optimize_above_cost=10000000;
SET
postgres=# set jit_inline_above_cost=10000000;
SET
postgres=# set jit=0;
SET
postgres=# explain verbose SELECT
    id,
    (SELECT count(*) FROM leak_test y WHERE y.id=l.id) as y_result
FROM leak_test l;
                                                 QUERY PLAN
------------------------------------------------------------------------------------------------------------
 Seq Scan on public.leak_test l  (cost=0.00..941723.86 rows=112965 width=12)
   Output: l.id, (SubPlan 1)
   SubPlan 1
     ->  Aggregate  (cost=8.31..8.32 rows=1 width=8)
           Output: count(*)
           ->  Index Only Scan using leak_test_pkey on
public.leak_test y  (cost=0.29..8.31 rows=1 width=0)
                 Output: y.id
                 Index Cond: (y.id = l.id)
(8 rows)

postgres=# set jit=1;
SET
postgres=# explain verbose SELECT
    id,
    (SELECT count(*) FROM leak_test y WHERE y.id=l.id) as y_result
FROM leak_test l;
server closed the connection unexpectedly

David



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Memory leak on subquery as scalar operand
Next
From: Tom Lane
Date:
Subject: Re: Memory leak on subquery as scalar operand