From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: terminate called after throwing an instance of 'std::bad_alloc' |
Date: | 2021-04-17 02:48:54 |
Message-ID: | 20210417024854.GL3315@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
CREATE OR REPLACE FUNCTION cfn() RETURNS void LANGUAGE PLPGSQL AS $$ declare a record; begin FOR a IN SELECT generate_series(1,99) LOOP PERFORM format('select 1'); END LOOP; END $$;
$ 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 2>&1 |grep 'max resident'
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-04-17 03:18:37 | Re: terminate called after throwing an instance of 'std::bad_alloc' |
Previous Message | Tom Lane | 2021-04-17 02:24:21 | Re: Bogus collation version recording in recordMultipleDependencies |