Re: Memory contexts reset for trigger invocations

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Memory contexts reset for trigger invocations
Дата
Msg-id 446A1DB2-A733-49FF-B00C-9CAE976FCFA5@anarazel.de
обсуждение исходный текст
Ответ на Re: Memory contexts reset for trigger invocations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On February 5, 2019 7:55:28 PM GMT+05:30, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.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
requiresheap 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.


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Memory contexts reset for trigger invocations
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Internal error while setting reloption on system catalogs.