Re: memory leak in trigger handling (since PG12)

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: memory leak in trigger handling (since PG12)
Date: 2023-07-02 20:26:35
Message-ID: d3acafd0-452e-070e-5891-d5e2f2d4370a@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/23/23 08:03, Alexander Pyhalov wrote:
> Tomas Vondra писал 2023-06-22 17:16:
>> On 6/22/23 13:46, Tomas Vondra wrote:
>>> ...
>>>
>>> I haven't tried the reproducer, but I think I see the issue - we store
>>> the bitmap as part of the event to be executed later, but the bitmap is
>>> in per-tuple context and gets reset. So I guess we need to copy it into
>>> the proper long-lived context (e.g. AfterTriggerEvents).
>>>
>>> I'll get that fixed.
>>>
>>
>> Alexander, can you try if this fixes the issue for you?
>>
>>
>> regard
>
> Hi.
> The patch fixes the problem and looks good to me.

Thanks, I've pushed the fix, including backpatch to 13+ (12 is not
affected by the oversight, the bitmap was added by 71d60e2aa0).

I think it'd be good to investigate if it's possible to compute the
bitmap only once - as already suggested by Andres, but that's a matter
for separate patch, not a bugfix.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2023-07-02 20:34:40 Re: Optionally using a better backtrace library?
Previous Message Laurenz Albe 2023-07-02 19:52:40 Re: Memory leak in incremental sort re-scan