I wrote:
> Alvaro Herrera <alvhe...@commandprompt.com> writes:
>> I was thinking that maybe it's time for this module to hook onto the
>> cleanup stuff for the xact error case; or at least have a check that it
>> has been properly cleaned up elesewhere.  Maybe this can be made to work
>> reentrantly if there's a global var holding the current context, and it
>> contains a link to the next one up the stack.  At least, my impression
>> is that the PG_TRY blocks are already messy.

> Yeah, that's another way we could go.  But I'm not sure how well it
> would interact with potential third-party modules setting up their own
> libxml error handlers.  Anybody have a thought about that?

I thought a bit more about this, and realized that there's a big
obstacle to getting rid of the PG_TRY blocks this way: most of them are
responsible for telling libxml to free some data structures, not just
restoring the error handler state.  We can't drop that aspect without
introducing session-lifespan memory leaks.

In principle we could expand the responsibilities of a
transaction-cleanup hook to include freeing data structures as well as
restoring error handlers, but the idea seems a lot messier and hence
less attractive than it did before.  I was ready to get rid of the
PG_TRY blocks until I came across this problem, but now I think I'll
stick with them.

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to