Re: [PATCH] plpython function causes server panic

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] plpython function causes server panic
Дата
Msg-id CA+TgmoZ=ttJYkqP+qMJG=N2z2gOFznyw9iH6vzft-wBg5D6Rmw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] plpython function causes server panic  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Mar 28, 2024 at 12:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Well, there's the abort case, too, which I think is almost equally important.
>
> True, but in the abort case there probably *are* resources to be
> cleaned up, so I'm not seeing that the fast-path idea helps.
> Although maybe the idea of batching multiple cleanups would?

Yes, I think we should be trying to optimize for the case where the
(sub)transaction being cleaned up holds a small but non-zero number of
resources. I think if we just optimize the case where it's exactly
zero, there will be enough cases where the optimization doesn't apply
that we'll feel like we haven't really solved the problem. Whether the
specific idea of trying to batch the cleanups could be made to help
enough to matter, I'm not quite sure. Another idea I had at one point
was to have some kind of bitmask where each bit tells you whether or
not one particular resource type might be held, so that
{Commit,Abort}{Sub,}Transaction would end up doing a bunch of stuff
like if (ResourcesNeedingCleanup & MIGHT_HOLD_THINGY)
AtEO(Sub)Xact_Thingy(...). But I wasn't sure that would really move
the needle, either. This seems to be one of those annoying cases where
the problem is much more obvious than the solution.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] plpython function causes server panic
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel