From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'
Date: Tue, 20 Apr 2021 20:03:13 -0500
Message-ID: <20210421010313.GR7256@telsasoft.com> (raw)
In-Reply-To: <20210421002056.gjd6rpe6toumiqd6@alap3.anarazel.de>
References: <20201007230242.rnwsbnxywvthef3w@alap3.anarazel.de>
<20201218235607.GC30237@telsasoft.com>
<20210417021755.xdcqaqqt4y46wzt7@alap3.anarazel.de>
<20210417024854.GL3315@telsasoft.com>
<20210417031837.GM3315@telsasoft.com>
<20210418001324.GP3315@telsasoft.com>
<20210419164130.byegpfrw46mzagcu@alap3.anarazel.de>
<20210420053826.GM7256@telsasoft.com>
<20210420055821.GA17201@telsasoft.com>
<20210421002056.gjd6rpe6toumiqd6@alap3.anarazel.de>
On Tue, Apr 20, 2021 at 05:20:56PM -0700, Andres Freund wrote:
> On 2021-04-20 00:58:21 -0500, Justin Pryzby wrote:
> > On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote:
> > > I don't know if this is related to the other issues, but this seems leaky.
> >
> > And it explains how the context use counter can exceed its threshold.
> >
> > create or replace function fn() returns void language plpgsql as $$ declare rec int; begin SELECT relpages INTO rec FROM pg_class LIMIT 1; end $$;
> Right - at the moment the context can only be recreated when there's no
> JITed queries ongoing. That's why I asked whether your "real" query
> contains function calls,
The real query has a bunch of function calls, including aggregates and custom
plpgsql functions. I reduced the whole thing to the above.
ts=# explain analyze SELECT fn() FROM generate_series(1,999);
! 71692 kB max resident size
ts=# explain analyze SELECT fn() FROM generate_series(1,9999);
! 332852 kB max resident size
Which doesn't seem to leak if I "SELECT 1 INTO rec" instead of "SELECT relpages
INTO rec".
> and whether those functions are expensive enough to be JITed.
The real query has:
| Append (cost=44.54..192946.35 rows=79 width=741)
That's a query over a 2 day period (midnight to midnight+2), so it's not hard
for me to believe it sometimes exceeds 100k cost units (jit_inline_above_cost),
depending on where we are in that interval, and on planner statistics. It
might've been different when I first reported the problem, too.
I'm not sure what you mean about expensive enough to be jited ?
I think our custom functions don't have a COST set.
explain analyze is showing:
JIT:
Functions: 201
--
Justin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, andres@anarazel.de, tgl@sss.pgh.pa.us
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'
In-Reply-To: <20210421010313.GR7256@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox