I've been poking at the problems described here: http://archives.postgresql.org/message-id/20090306191404.gk3...@alvh.no-ip.org http://archives.postgresql.org/message-id/5265.1240417...@sss.pgh.pa.us
I've about come to the conclusion that the only real fix is to abandon our attempt to manage libxml's memory usage. Although clearing out whatever it's allocated at transaction end is safe from Postgres' own point of view, we cannot really assume that third-party code that also depends on libxml will think the same. What we have to do instead is let it use malloc() directly and add PG_TRY() hacks as necessary to ensure that transient data structures get cleared on error exits. This has a number of disadvantages of course: 1. We are exposed to any internal memory leak or failure-to-check-for-null- return-from-malloc bugs that may lurk inside libxml. However, it's hard to argue that introducing known bugs of our own is a good tradeoff for hiding someone else's possible bugs. We should take the attitude that a libxml bug is a libxml bug, not our problem. 2. Any cleanup we miss making will result in a long-term memory leak that accumulates across transactions. However, any such cleanup that we are missing already represents an intratransaction leak, which will build up with just as much vigor if the XML functions are called repeatedly in one transaction. So it's not clear that the current solution is buying much on this score either. 3. The code in xml.c will be a lot uglier :-(. We have a prototype, which is the coding that was used in xml.c during most of 8.3 beta. It's not real fun but at least the changes are localized. This is a sufficiently large change that I'd not risk back-porting it into 8.3, but I think it is the way to proceed for 8.4 and beyond. Objections, better ideas? 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