From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: memory leak in trigger handling (since PG12)
In-reply-to: <20230523171433.earidmyzock7fnk4@awork3.anarazel.de>
References: <222a3442-7f7d-246c-ed9b-a76209d19239@enterprisedb.com> <20230523171433.earidmyzock7fnk4@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 23 May 2023 10:14:33 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <965726.1684862910.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 May 2023 13:28:30 -0400
Message-ID: <965727.1684862910@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/965727.1684862910%40sss.pgh.pa.us>
Precedence: bulk

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 6=
3 bits
> are in-place, if unset, it's a pointer).

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

			regards, tom lane