Horton

Re: memory leak in trigger handling (since PG12)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2023-05-23T18:33:27Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2023-05-23 13:28:30 -0400, Tom Lane wrote:
>> Why?  Unlike Lists, those things are already a single palloc chunk.

> We do a fair amount of 8 byte allocations - they have quite a bit of overhead,
> even after c6e0fe1f2a0. Not needing allocations for the common case of
> bitmapsets with a max member < 63 seems like it could be worth it.

Oh, now I understand what you meant: use the pointer's bits as data.
Dunno that it's a good idea though.  You'd pay for the palloc savings
by needing two or four code paths in every bitmapset function, because
the need to reserve one bit would mean you couldn't readily make the
two cases look alike at the bit-pushing level.

Another big problem is that we'd have to return to treating bitmapsets
as a special-purpose thing rather than a kind of Node.  While that's
not very deeply embedded yet, I recall that the alternatives weren't
attractive.

Also, returning to the original topic: we'd never find leaks of the
sort complained of here, because they wouldn't exist in cases with
fewer than 64 relations per query (or whatever the bitmap is
representing).

			regards, tom lane

Commits

  1. Fix oversight in handling of modifiedCols since f24523672d

  2. Use per-tuple context in ExecGetAllUpdatedCols

  3. Generated columns