Date: Sun, 16 May 2021 19:29:36 -0500
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'
Message-ID: <20210517002936.GD373@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210419174136.GJ7256@telsasoft.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210517002936.GD373%40telsasoft.com>
Precedence: bulk

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);"