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
