From: | "Andreas 'ads' Scherbaum" <ads(at)pgug(dot)de> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Crash: invalid DSA memory alloc request |
Date: | 2024-12-17 07:00:00 |
Message-ID: | CAMDzVO_Tu=rvLKQe5MPAoY7PexkNAMXLFMjCrx4UGsLpc0kJQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
On Mon, Dec 16, 2024 at 11:18 PM Nathan Bossart <nathandbossart(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Evgeny Voropaev | 2024-12-17 07:28:07 | Re: Add 64-bit XIDs into PostgreSQL 15 |
Previous Message | Michael Paquier | 2024-12-17 06:28:51 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |