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: Sun, 16 May 2021 19:29:36 -0500
Message-ID: <20210517002936.GD373@telsasoft.com> (raw)
In-Reply-To: <20210419174136.GJ7256@telsasoft.com>
References: <20201003233045.GM8476@telsasoft.com>
<20201004020127.zbrol2ypu6tg2bei@alap3.anarazel.de>
<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>
<20210419174136.GJ7256@telsasoft.com>
I think you were thinking that the jit_inline_above_cost=0 for queries within
plpgsql functions is pathological and not a useful test case, since the
function can be called an arbitrarily large number of times, but the jit
context can't be reset mid-query due to nonzero reference count.
I think you were wondering whether in our normal environment the plpgsql
functions run queries that are expensive enough to be jitted. I think they're
not expensive enough to be JITed - but it makes debugging/diagnosing/testing
much harder if it somehow "doesn't count" to set inline_above_cost=0.
I think that means 1) it's still a memory leak, since it's O(ntuples), which is
not generally okay....but, 2) it's certainly better than nothing. It'd be good
enough for back branches to have a mitigation rather than be killed by OOM.
I'd forgotten doing it, but I had run your patch on one of the servers which
first crashed. I remembered after upgrading to v13.3 and having the processed
killed by OOM twice per day for the last 3 days (on a very consistent
schedule).
Could you provide a patch to apply to v13 ? My attempted backpatch introduced
some issues.
On Mon, Apr 19, 2021 at 12:41:36PM -0500, Justin Pryzby wrote:
> > > Also, I just hit this assertion by cancelling the query with ^C / sigint. But
> > > I don't have a reprodcer for it.
> > >
> > > < 2021-04-17 19:14:23.509 ADT telsasoft >PANIC: LLVMJitContext in use count not 0 at exit (is 1)
> >
> > Hm, I'll try to see how that happens - if not, do you have a backtrace?
>
> This may be because I backpatched to v13, which had one conflict (0a2bc5d61).
> Maybe this is relevant, too: bab150045
>
> If you could provide a patch for v13, it's a good bet there's no issue that I
> didn't cause.
>
> I'm able to reproduce the crash like this, with my patch to v13, but not your
> patch on master.
>
> python3 -c "import pg; db=pg.DB('dbname=postgres'); db.query('SET jit_above_cost=0; SET jit_inline_above_cost=0; SET jit=on; SET client_min_messages=debug'); db.query('begin'); db.query_formatted('SELECT 1 FROM generate_series(1,99)a WHERE a=%s', [1], inline=False);"
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: <20210517002936.GD373@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