User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249
Mime-Version: 1.0
Message-Id: <21486531-e1bd-4c7e-aa2c-938093855f66@www.fastmail.com>
In-Reply-To: <20210417031837.GM3315@telsasoft.com>
References: <20201001021609.GC8476@telsasoft.com>
 <20201003220236.GL8476@telsasoft.com>
 <20201003230149.mtd7fjsjwgii3jv7@alap3.anarazel.de>
 <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>
Date: Fri, 16 Apr 2021 21:40:12 -0700
From: "Andres Freund" <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'
Content-Type: text/plain
Archived-At: 
 <https://www.postgresql.org/message-id/21486531-e1bd-4c7e-aa2c-938093855f66%40www.fastmail.com>
Precedence: bulk

Hi,

On Fri, Apr 16, 2021, at 20:18, Justin Pryzby wrote:
> On Fri, Apr 16, 2021 at 09:48:54PM -0500, Justin Pryzby wrote:
> > On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> > > Hi,
> > > 
> > > On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > > > I'd be happy to run with a prototype fix for the leak to see if the other issue
> > > > does (not) recur.
> > > 
> > > I just posted a prototype fix to https://www.postgresql.org/message-id/20210417021602.7dilihkdc7oblrf7%40alap3.anarazel.de
> > > (just because that was the first thread I re-found). It'd be cool if you
> > > could have a look!
> > 
> > This doesn't seem to address the problem triggered by the reproducer at
> > https://www.postgresql.org/message-id/20210331040751.GU4431@telsasoft.com
> > (sorry I didn't CC you)
> 
> I take that back - I forgot that this doesn't release RAM until hitting a
> threshold.
> 

Phew.

> Without the patch, it looks like:
> 
> $ yes 'SET jit_above_cost=0; SET jit_inline_above_cost=0; SET jit=on; 
> SET client_min_messages=debug; SET log_executor_stats=on; SELECT 
> cfn();' |head -11 |psql -h /tmp postgres 2>&1 |grep 'max resident'
> !       61820 kB max resident size
> !       65020 kB max resident size
> !       68812 kB max resident size
> !       71152 kB max resident size
> !       76820 kB max resident size
> !       78760 kB max resident size
> !       81140 kB max resident size
> !       83520 kB max resident size
> !       93084 kB max resident size
> !       94756 kB max resident size
> !       96416 kB max resident size
> 
> With the patch and #define LLVMJIT_LLVM_CONTEXT_REUSE_MAX 1, it looks like
> this:
> 
> !       61436 kB max resident size
> !       61572 kB max resident size
> !       63236 kB max resident size
> !       63236 kB max resident size
> !       63556 kB max resident size
> !       63556 kB max resident size
> !       63880 kB max resident size
> !       65416 kB max resident size
> !       65416 kB max resident size
> !       65416 kB max resident size
> !       65416 kB max resident size

If you set the define to much lower, how low does this get? I didn't see an easy way to make the recreation of the context memory usage dependant, but that'd of course be much better than an #iterations based approach. I'll play around with your test tomorrow or so, if you don't, but now the next step is risotto...

Regards,

Andres