Re: Memory contexts reset for trigger invocations

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Memory contexts reset for trigger invocations
Date: 2019-02-05 14:55:27
Message-ID: 446A1DB2-A733-49FF-B00C-9CAE976FCFA5@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On February 5, 2019 7:55:28 PM GMT+05:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> 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?
>
>I'm not sure that we can change much here without effectively breaking
>the trigger-function API.

HM, why? If we copy the tuple into a longer lived context we ought to be able to reset more aggressively.

I doubt that there's enough win to be had
>to justify forcing external PLs etc to change.
>
>Having said that, I recall that that API was kind of a pain in the
>rear when I was redoing plpgsql's handling of composite variables
>last year. Don't recall details right now (ENOCAFFEINE). Maybe
>a wholesale rethink would be justified? But I'm not excited about
>just twiddling things at the margin.

Yea, we probably ought to: The pluggable storage patch set makes trigger.c use slots. But the trigger interface requires heap tuples, so we extract heap tuples. But probably it'd be go full in slots at some point.

Regards,

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-05 15:01:48 Re: Internal error while setting reloption on system catalogs.
Previous Message Tom Lane 2019-02-05 14:25:28 Re: Memory contexts reset for trigger invocations