Re: Memory contexts reset for trigger invocations
От | Haribabu Kommi |
---|---|
Тема | Re: Memory contexts reset for trigger invocations |
Дата | |
Msg-id | CAJrrPGctxU9LDpACFCnBpPC0zCSo-KP77m50jDJ8S09QZfaryA@mail.gmail.com обсуждение исходный текст |
Ответ на | Memory contexts reset for trigger invocations (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Tue, Feb 5, 2019 at 4:29 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
trigger.c goes through some trouble to free the tuples returned by
trigger functions. There's plenty codepaths that look roughly like:
if (oldtuple != newtuple && oldtuple != slottuple)
heap_freetuple(oldtuple);
if (newtuple == NULL)
{
if (trigtuple != fdw_trigtuple)
heap_freetuple(trigtuple);
return NULL; /* "do nothing" */
}
but we, as far as I can tell, do not reset the memory context in which
the trigger functions have been called.
Wouldn't it be better to reset an appropriate context after each
invocation? Yes, that'd require some care to manage the lifetime of
tuples returned by triggers, but that seems OK?
Currently the trigger functions are executed under per tuple memory
context, but the returned tuples are allocated from the executor memory
context in some scenarios.
/*
* Copy tuple to upper executor memory. But if user just did
* "return new" or "return old" without changing anything, there's
* no need to copy; we can return the original tuple (which will
* save a few cycles in trigger.c as well as here).
*/
if (rettup != trigdata->tg_newtuple &&
rettup != trigdata->tg_trigtuple)
rettup = SPI_copytuple(rettup);
* Copy tuple to upper executor memory. But if user just did
* "return new" or "return old" without changing anything, there's
* no need to copy; we can return the original tuple (which will
* save a few cycles in trigger.c as well as here).
*/
if (rettup != trigdata->tg_newtuple &&
rettup != trigdata->tg_trigtuple)
rettup = SPI_copytuple(rettup);
we need to take care of these also before switch to a context?
Regards,
Haribabu Kommi
Fujitsu Australia
В списке pgsql-hackers по дате отправления: