Re: Fixing the libxml memory allocation situation - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Fixing the libxml memory allocation situation
Date
Msg-id 20090518144552.GC7741@svana.org
Whole thread Raw
In response to Fixing the libxml memory allocation situation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing the libxml memory allocation situation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 12, 2009 at 05:55:13PM -0400, Tom Lane wrote:
> I've been poking at the problems described here:
> http://archives.postgresql.org/message-id/20090306191404.GK3901@alvh.no-ip.org
> http://archives.postgresql.org/message-id/5265.1240417987@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.

Perhaps we could suggest to the libxml authors that it would be nice of
the allocation functions could be controlled in a non-global way, so
that different users of the same library can control their own memory
usage without affecting others.

Not a short term solution, but it might help longer term. We certainly
have enough examples to convince them of the problem.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: problem with polymorphic functions and implicit casting
Next
From: Tom Lane
Date:
Subject: Re: Fixing the libxml memory allocation situation