Re: Crash: invalid DSA memory alloc request

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, 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 15:53:07
Message-ID: osoawto55h5vrujdw4gvcl4oc5ivpyqhojcczvkvs2ww26om2g@rnppaufqrdjj
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-12-17 16:50:45 +0900, Michael Paquier wrote:
> 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.

I don't see why we wouldn't want to backpatch? The number of objects here
isn't entirely unrealistic to reach with relations alone, and if you enable
e.g. function execution stats it can reasonably reach higher numbers more
quickly. And use DSA_ALLOC_HUGE in that place feels like a rather low risk
change?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2024-12-17 15:56:59 Re: Eagerly scan all-visible pages to amortize aggressive vacuum
Previous Message Robert Haas 2024-12-17 15:50:56 Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?