Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matt Magoffin <postgresql(dot)org(at)msqr(dot)us>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions
Date: 2021-12-04 20:04:15
Message-ID: 2693283.1638648255@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Matt Magoffin <postgresql(dot)org(at)msqr(dot)us> writes:
> On 5/12/2021, at 5:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2021-12-04 21:43:48 Re: libpq: Which functions may hang due to network issues?
Previous Message Matt Magoffin 2021-12-04 17:56:07 Re: Handling memory contexts in aggregate function invoking other built-in aggregate functions