Re: [PATCH] plpython function causes server panic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] plpython function causes server panic
Дата
Msg-id 3578287.1711637941@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:
> I sort of assumed you were going to commit the patch as you had it.

OK, I will move ahead on that.

> I actually
> really wish we could find some way of making subtransactions
> significantly lighter-wait, because I think the cost of spinning up
> and tearing down a trivial subtransaction is a real performance
> problem, but fixing that is probably a pretty hard problem whether
> this patch gets committed or not.

Yeah.  The whole ResourceOwner mechanism is not exactly lightweight,
but it's hard to argue that we don't need it.  I wonder whether we
could get anywhere by deeming that a "small enough" subtransaction
doesn't need to have its resources cleaned up instantly, and
instead re-use its ResourceOwner to accumulate resources of the
next subtransaction, and the next, until there's enough to be
worth cleaning up.

Having said that, it's hard to see any regime under which tied-up
parallel workers wouldn't count as a resource worth releasing ASAP.
I started this mail with the idea of suggesting that parallel contexts
ought to become a ResourceOwner-managed resource, but maybe that
wouldn't be an improvement after all.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] plpython function causes server panic
Следующее
От: Alexander Lakhin
Дата:
Сообщение: [MASSMAIL]To what extent should tests rely on VACUUM ANALYZE?