| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Andreas 'ads' Scherbaum <ads(at)pgug(dot)de>, 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:50:45 |
| Message-ID: | Z2EtVQOJHs5Ld7G1@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2024-12-17 08:13:59 | Re: per backend I/O statistics |
| Previous Message | Michael Paquier | 2024-12-17 07:43:21 | Re: [PATCH] Add support for displaying database service in psql prompt |