Re: Crash: invalid DSA memory alloc request
| От | Andreas 'ads' Scherbaum |
|---|---|
| Тема | Re: Crash: invalid DSA memory alloc request |
| Дата | |
| Msg-id | CAMDzVO_Tu=rvLKQe5MPAoY7PexkNAMXLFMjCrx4UGsLpc0kJQg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Crash: invalid DSA memory alloc request (Nathan Bossart <nathandbossart@gmail.com>) |
| Список | 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
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
В списке pgsql-hackers по дате отправления: