Re: memory leak in trigger handling (since PG12)

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: memory leak in trigger handling (since PG12)
Дата
Msg-id 36e564f7-6cde-927d-9089-19471a05e8f3@enterprisedb.com
обсуждение исходный текст
Ответ на Re: memory leak in trigger handling (since PG12)  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
Ответы Re: memory leak in trigger handling (since PG12)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers

On 6/22/23 13:07, Alexander Pyhalov wrote:
> Tomas Vondra писал 2023-05-25 17:41:
> 
>> The attached patch does this - I realized we actually have estate in
>> ExecGetAllUpdatedCols(), so we don't even need a variant with a
>> different signature. That makes the patch much simpler.
>>
>> The question is whether we need the signature anyway. There might be a
>> caller expecting the result to be in CurrentMemoryContext (be it
>> ExecutorState or something else), and this change might break it. But
>> I'm not aware of any callers, so maybe that's fine.
>>
> 
> Hi.
> Unfortunately, this patch has broken trigdata->tg_updatedcols usage in
> AFTER UPDATE triggers.
> Should it be if not fixed, but at least mentioned in documentation?
> 

That's clearly a bug, we can't just break stuff like that.

> Attaching sample code. After creating trigger, an issue can be
> reproduced as this:
> 
> create table test (i int, j int);
> create function report_update_fields() RETURNS TRIGGER AS
> '/location/to/trig_test.so' language C;
> create trigger test_update after update ON test FOR EACH ROW EXECUTE
> FUNCTION report_update_fields();
> insert into test values (1, 12);
> update test set j=2;
> 

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.

Anyway, this probably hints we should not recalculate the bitmap over
and over, but calculate it once and keep it for all events. Not
something we can do in backbranches, though.


regards

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Partial aggregates pushdown
Следующее
От: Ranier Vilela
Дата:
Сообщение: Re: Making empty Bitmapsets always be NULL