Re: memory leak in trigger handling (since PG12) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: memory leak in trigger handling (since PG12)
Date
Msg-id 965727.1684862910@sss.pgh.pa.us
Whole thread Raw
In response to Re: memory leak in trigger handling (since PG12)  (Andres Freund <andres@anarazel.de>)
Responses Re: memory leak in trigger handling (since PG12)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I've wondered about some form of instrumentation to detect such issues
> before.

Yeah.

> Could it help to have a mode where the executor shutdown hook checks how much
> memory is allocated in ExecutorState and warns if its too much?

It'd be very hard to set a limit for what's "too much", since the amount
of stuff created initially will depend on the plan size.  In any case
I think that the important issue is not how much absolute space, but is
there per-row leakage.  I wonder if we could do something involving
checking for continued growth after the first retrieved tuple, or
something like that.

> Random aside: I've been wondering whether it'd be worth introducing an
> in-place representation of Bitmap (e.g. if the low bit is set, the low 63 bits
> are in-place, if unset, it's a pointer).

Why?  Unlike Lists, those things are already a single palloc chunk.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: memory leak in trigger handling (since PG12)
Next
From: "Tristan Partin"
Date:
Subject: Use COPY for populating all pgbench tables