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 [email protected]
Whole thread Raw
In response to Re: terminate called after throwing an instance of 'std::bad_alloc'  (Andres Freund <[email protected]>)
Responses Re: terminate called after throwing an instance of 'std::bad_alloc'
List 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/[email protected]
(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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bogus collation version recording in recordMultipleDependencies
Next
From: Justin Pryzby
Date:
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'