Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions - Mailing list pgsql-general

From Tom Lane
Subject Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions
Date
Msg-id 2693283.1638648255@sss.pgh.pa.us
Whole thread Raw
In response to Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions  (Matt Magoffin <postgresql.org@msqr.us>)
Responses Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions  (Matt Magoffin <postgresql.org@msqr.us>)
List pgsql-general
Matt Magoffin <postgresql.org@msqr.us> writes:
> On 5/12/2021, at 5:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Are you testing in an --enable-cassert build?  If not, do that;
>> it might make the cause of the crashes more apparent, thanks to
>> CLOBBER_FREED_MEMORY and other debug support.

> I did build with --enable-cassert, and I did see the state argument pointer passed to numeric_avg_accum
>  as 0x7f7f7f7f7f, so now I understand why that was thanks to seeing the information about what that means on the Dev
FAQ,thanks for that. 

So that probably means that you weren't careful about allocating your
own state data in the long-lived context (agg_context), and so it
got freed between calls.

            regards, tom lane



pgsql-general by date:

Previous
From: Matt Magoffin
Date:
Subject: Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions
Next
From: Laurenz Albe
Date:
Subject: Re: libpq: Which functions may hang due to network issues?