Tom Lane wrote:
> I'm beginning to think nobody is going to step up and fix contrib/xml2,
> so I had a look at it myself. It strikes me that there is a pretty
> simple fix for it: just get rid of the attempt to manage libxml memory
> via palloc, and don't do anything else. The implication of this will
> be that if an error is thrown out of one of the libxml2 functions,
> we'll leak whatever memory libxml2 was using for the current document
> (for the life of the session). While this isn't great, it sure beats
> crashing; and it seems like it might be about the appropriate level of
> effort for a contrib module that's slated for destruction anyhow.
> It looks to me like the only really probable elog cause within those
> functions is out-of-memory, and even that wouldn't be very probable in
> normal use. So sticking in PG_TRY/PG_CATCH logic would be a significant
> increment in effort for only very marginal returns.
>
> Comments, objections?
FYI, I created a web page of all the open xml items:
http://momjian.us/cgi-bin/pgsql/mbox?xml
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do