Re: Fixing the libxml memory allocation situation

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Fixing the libxml memory allocation situation
Date: 2009-05-18 14:45:52
Message-ID: 20090518144552.GC7741@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-18 15:13:38 Re: Fixing the libxml memory allocation situation
Previous Message Pavel Stehule 2009-05-18 12:09:50 problem with polymorphic functions and implicit casting