Horton

Re: Crash: invalid DSA memory alloc request

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andreas 'ads' Scherbaum <ads@pgug.de>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-17T07:50:45Z
Lists: pgsql-hackers 
On Mon, Dec 16, 2024 at 04:18:26PM -0600, Nathan Bossart wrote:
> On Mon, Dec 16, 2024 at 08:00:00AM +0100, Andreas 'ads' Scherbaum wrote:
>> Can confirm that the crash no longer happens when applying your patch.
> 
> The patch looks reasonable to me.  I'll commit it soon unless someone
> objects.  I was surprised to learn that the DSA_ALLOC_HUGE flag is only
> intended to catch faulty allocation requests [0].

No objections.

Most likely this issue gets by a large degree easier to reach now that
we can plug into the backend custom pgstats kinds.  If pgstats or an
equivalent implementation uses pgstats, I don't think that we'll be
able to live without lifting this limit (500k query entries are
common, at 2kB each it would be enough to blow things), so using
DSA_ALLOC_HUGE sounds good to me.  I don't see a huge point in
backpatching, FWIW.

>>  20000211
> 
> That's a lot of tables...
> 
> [0] https://postgr.es/m/28062.1487456862%40sss.pgh.pa.us

And most likely don't do that.  If you want to play more in this area,
there is also the join-1M-tables-in-a-single-query game.
--
Michael

Commits

  1. Accommodate very large dshash tables.