Re: unconstrained memory growth in long running procedure stored procedure after upgrading 11-12 - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: unconstrained memory growth in long running procedure stored procedure after upgrading 11-12
Date
Msg-id 20210330234612.GA3617@telsasoft.com
Whole thread Raw
In response to unconstrained memory growth in long running procedure stored procedure after upgrading 11-12  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: unconstrained memory growth in long running procedure stored procedure after upgrading 11-12  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Mar 30, 2021 at 04:17:03PM -0500, Merlin Moncure wrote:
> Hello all,
> 
> We just upgraded from postgres 11 to 12.6 and our server is running
> out of memory and rebooting about 1-2 times a day.    Application
> architecture is a single threaded stored procedure, executed with CALL
> that loops and never terminates. With postgres 11 we had no memory
> issues.  Ultimately the crash looks like this:
> 
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> 2021-03-29 04:34:31.262 CDT [1413] LOG:  server process (PID 9792) was
> terminated by signal 6: Aborted

I haven't tried your test, but this sounds a lot like the issue I reported with
JIT, which is enabled by default in v12.

https://www.postgresql.org/docs/12/release-12.html
Enable Just-in-Time (JIT) compilation by default, if the server has been built with support for it (Andres Freund)
Note that this support is not built by default, but has to be selected explicitly while configuring the build.

https://www.postgresql.org/message-id/20201001021609.GC8476%40telsasoft.com
terminate called after throwing an instance of 'std::bad_alloc'

I suggest to try ALTER SYSTEM SET jit_inline_above_cost=-1; SELECT pg_reload_conf();

> memory growth immediately.   It's about a gigabyte an hour in my test.
> Sorry for the large-ish attachment.

Your reproducer is probably much better than mine was.

-- 
Justin



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: What to call an executor node which lazily caches tuples in a hash table?
Next
From: Zhihong Yu
Date:
Subject: Re: What to call an executor node which lazily caches tuples in a hash table?