Re: terminate called after throwing an instance of 'std::bad_alloc' - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: terminate called after throwing an instance of 'std::bad_alloc'
Date
Msg-id 20210517002936.GD373@telsasoft.com
Whole thread Raw
In response to Re: terminate called after throwing an instance of 'std::bad_alloc'  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: terminate called after throwing an instance of 'std::bad_alloc'
List pgsql-hackers
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
WHEREa=%s', [1], inline=False);"
 



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Typo in README.barrier
Next
From: Tatsuo Ishii
Date:
Subject: Re: Typo in README.barrier