From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memory contexts reset for trigger invocations |
Date: | 2019-02-05 07:19:38 |
Message-ID: | CAJrrPGctxU9LDpACFCnBpPC0zCSo-KP77m50jDJ8S09QZfaryA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 5, 2019 at 4:29 PM Andres Freund <andres(at)anarazel(dot)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);
we need to take care of these also before switch to a context?
>
Regards,
Haribabu Kommi
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-02-05 07:26:18 | Re: Tighten up a few overly lax regexes in pg_dump's tap tests |
Previous Message | Andres Freund | 2019-02-05 07:01:43 | Re: Online verification of checksums |