Justin Pryzby writes:
> On Sat, Apr 15, 2023 at 11:33:58AM +1200, David Rowley wrote:
>> Any chance you could try and come up with a minimal reproducer?
> Try this
Thanks. I see the problem: finalize_aggregate is no longer forcing
a R/W expanded datum returned by the finalfn into R/O form. If
On Sat, Apr 15, 2023 at 11:33:58AM +1200, David Rowley wrote:
> On Sat, 15 Apr 2023 at 10:48, Justin Pryzby 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?
David Rowley writes:
> I don't think that's really going to help. The crash already tells us
> there's a problem down the line, but if the commit you mention is to
> blame for this, then the problem is elsewhere, either in our
> assumption that we can get away without the datumCopy() or in the
>
On Sat, 15 Apr 2023 at 13:03, Justin Pryzby wrote:
> Maybe you'll find valgrind errors to be helpful.
I don't think that's really going to help. The crash already tells us
there's a problem down the line, but if the commit you mention is to
blame for this, then the problem is elsewhere, either i
Maybe you'll find valgrind errors to be helpful.
==17971== Source and destination overlap in memcpy(0x1eb8c078, 0x1d88cb20,
123876054)
==17971==at 0x4C2E81D: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1035)
==17971==by 0x9C705A: memcpy (string3.h:51)
==17971==by 0x9C705A: pg_detoast_datu
David Rowley writes:
> Any chance you could try and come up with a minimal reproducer?
Yeah --- there's an awful lot of moving parts there, and a stack
trace is not much to go on.
regards, tom lane
On Sat, 15 Apr 2023 at 10:48, Justin Pryzby 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
On Sat, Apr 15, 2023 at 10:04:52AM +1200, David Rowley wrote:
> On Sat, 15 Apr 2023 at 08:36, Justin Pryzby wrote:
> >
> > I hit this elog() while testing reports under v16 and changed to PANIC
> > to help diagnose.
> >
> > DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
>
On Sat, 15 Apr 2023 at 08:36, Justin Pryzby wrote:
>
> I hit this elog() while testing reports under v16 and changed to PANIC
> to help diagnose.
>
> DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
> CONTEXT: PL/pgSQL function array_weight(real[],real[]) while storing call
I hit this elog() while testing reports under v16 and changed to PANIC
to help diagnose.
DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
CONTEXT: PL/pgSQL function array_weight(real[],real[]) while storing call
arguments into local variables
I can't share the query, data
10 matches
Mail list logo
