Re: [PATCH] plpython function causes server panic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] plpython function causes server panic
Дата
Msg-id 3583862.1711641030@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] plpython function causes server panic  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PATCH] plpython function causes server panic  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Hmm, I wonder if that's actually where the cycles are going. There's
> an awful lot of separate function calls inside CommitSubTransaction(),
> and in the common case, each one of them has to individually decide
> that it doesn't need to do anything. Sure, they're all fast, but if
> you have enough of them, it's still going to add up, at least a bit.
> In that sense, the resource owner mechanism seems like it should, or
> at least could, be better.

Yeah, I was thinking about that too.  The normal case is that you
don't hold any releasable resources except locks when arriving at
CommitSubTransaction --- if you do, it's a bug and we're going to
print leak warnings.  Seems like maybe it'd be worth trying to
have a fast path for that case.  (Also, given that we probably
do need to release locks right away, this point invalidates my
earlier idea of postponing the work.)

> But I haven't done any benchmarking of this area in a long time.

Ditto.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] plpython function causes server panic
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables