Re: memory leak in trigger handling (since PG12)

Поиск
Список
Период
Сортировка
От Alexander Pyhalov
Тема Re: memory leak in trigger handling (since PG12)
Дата
Msg-id acddb17c89b0d6cb940eaeda18c08bbe@postgrespro.ru
обсуждение исходный текст
Ответ на Re: memory leak in trigger handling (since PG12)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: memory leak in trigger handling (since PG12)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
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?

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;

-- 
Best regards,
Alexander Pyhalov,
Postgres Professional
Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Partial aggregates pushdown