Re: v16dev: invalid memory alloc request size 8488348128 - Mailing list pgsql-hackers

From David Rowley
Subject Re: v16dev: invalid memory alloc request size 8488348128
Date
Msg-id CAApHDvq9HR1-SJfQP8+-tphmbABWzL6r87y92+UxKHz3yhqdqQ@mail.gmail.com
Whole thread Raw
In response to Re: v16dev: invalid memory alloc request size 8488348128  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: v16dev: invalid memory alloc request size 8488348128
Re: v16dev: invalid memory alloc request size 8488348128
Re: v16dev: invalid memory alloc request size 8488348128
List pgsql-hackers
On Sat, 15 Apr 2023 at 10:48, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Sat, Apr 15, 2023 at 10:04:52AM +1200, David Rowley wrote:
> > Which aggregate function is being called here?  Is it a custom
> > aggregate written in C, by any chance?
>
> That function is not an aggregate:

There's an aggregate somewhere as indicated by this fragment from the
stack trace:

> #12 project_aggregates (aggstate=aggstate@entry=0x607200070d38) at ../src/backend/executor/nodeAgg.c:1377
> #13 0x0000000000903eb6 in agg_retrieve_direct (aggstate=aggstate@entry=0x607200070d38) at
../src/backend/executor/nodeAgg.c:2520
> #14 0x0000000000904074 in ExecAgg (pstate=0x607200070d38) at ../src/backend/executor/nodeAgg.c:2172

Any chance you could try and come up with a minimal reproducer?  You
have access to see which aggregates are being used here and what data
types are being given to them and then what's being done with the
return value of that aggregate that's causing the crash.  Maybe you
can still get the crash if you mock up some data to aggregate and
strip out the guts from the plpgsql functions that we're crashing on?

David



pgsql-hackers by date:

Previous
From: Amin
Date:
Subject: Scans are offloaded to SeqScan instead of CustomScan when there are multiple relations in the same query
Next
From: Thomas Munro
Date:
Subject: Re: Direct I/O