Re: [PATCH] plpython function causes server panic - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] plpython function causes server panic
Date
Msg-id 3578287.1711637941@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] plpython function causes server panic  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] plpython function causes server panic
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] plpython function causes server panic
Next
From: Alexander Lakhin
Date:
Subject: [MASSMAIL]To what extent should tests rely on VACUUM ANALYZE?