Horton

Re: v16dev: invalid memory alloc request size 8488348128

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org
Date: 2023-04-15T03:27:49Z
Lists: pgsql-hackers 
David Rowley <dgrowleyml@gmail.com> 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
> aggregate function producing the state that we're no longer copying.

It does smell like the aggregate output has been corrupted by the time
it got to the plpgsql function.  I don't particularly want to try to
synthesize a test case from the essentially-zero SQL-level information
we've been provided, though.  And I doubt we can track this down without
a test case.  So please try to sanitize the case you have enough that
you can share it.

			regards, tom lane

Commits

  1. Ensure result of an aggregate's finalfunc is made read-only.

  2. Remove uses of MemoryContextContains in nodeAgg.c and nodeWindowAgg.c.

  3. Fix pg_upgrade to detect non-upgradable anyarray usages.

  4. Work around cross-version-upgrade issues created by commit 9e38c2bb5.

  5. Declare assorted array functions using anycompatible not anyelement.