Horton

Re: Crash: invalid DSA memory alloc request

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, Andreas 'ads' Scherbaum <ads@pgug.de>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-17T17:22:34Z
Lists: pgsql-hackers 
On Tue, Dec 17, 2024 at 10:53:07AM -0500, Andres Freund wrote:
> On 2024-12-17 16:50:45 +0900, Michael Paquier wrote:
>> I don't see a huge point in backpatching, FWIW.
> 
> I don't see why we wouldn't want to backpatch? The number of objects here
> isn't entirely unrealistic to reach with relations alone, and if you enable
> e.g. function execution stats it can reasonably reach higher numbers more
> quickly. And use DSA_ALLOC_HUGE in that place feels like a rather low risk
> change?

Agreed, this feels low-risk enough to back-patch to at least v15, where
statistics were moved to shared memory.  But I don't see a strong reason to
avoid back-patching it to all supported versions, either.

-- 
nathan

Commits

  1. Accommodate very large dshash tables.