From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Another issue with invalid XML values |
Date: | 2011-07-20 14:08:32 |
Message-ID: | 10430.1311170912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2011-07-20 14:15:40 | Re: [v9.2] Fix leaky-view problem, part 2 |
Previous Message | Noah Misch | 2011-07-20 14:06:26 | Re: [v9.2] Fix leaky-view problem, part 2 |