Re: memory leak in trigger handling (since PG12)

Andres Freund <andres(at)anarazel(dot)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