Re: Crash: invalid DSA memory alloc request
Andreas 'ads' Scherbaum <ads@pgug.de>
From: "Andreas 'ads' Scherbaum" <ads@pgug.de>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-17T07:00:00Z
Lists: pgsql-hackers
Hello, On Mon, Dec 16, 2024 at 11:18 PM Nathan Bossart <nathandbossart@gmail.com> 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]. > Is there a way to test it, except by creating so many tables? There might be more such problems. I did run a few basic queries in the database, but that's far from a full test. > > Was able to both continue the old and crashed test, as well as run a new > > test: > > > > tabletest=# select count(*) from information_schema.tables; > > count > > ---------- > > 20000211 > > (1 row) > > That's a lot of tables... > Started as a discussion, got me curious and it's only about a magnitude or so off from what I've seen in production. Not unrealistic to find out when and where it breaks. Thanks, -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project
Commits
-
Accommodate very large dshash tables.
- 9f7b7d5168ac 15.11 landed
- 853cef097666 13.19 landed
- 84f1b0b031e6 18.0 landed
- 84dc1303c963 14.16 landed
- 2a74023221f9 16.7 landed
- 18452b70acee 17.3 landed