Re: remove contrib/xml2

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: M Z <jm80008(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: remove contrib/xml2
Date: 2010-02-18 14:09:45
Message-ID: 20100218140945.GA6317@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

M Z escribió:
> Hi Alvaro,
>
> I followed your instruction but put the patch on 8.4.2 as I found it
> crashes. It looks like the server still crash in the same way. Can you and
> anyone give me some ideas how to fix this bug?

See src/backend/utils/adt/xml.c. Note the comment at the top:

/*
* Notes on memory management:
*
* Sometimes libxml allocates global structures in the hope that it can reuse
* them later on. This makes it impractical to change the xmlMemSetup
* functions on-the-fly; that is likely to lead to trying to pfree() chunks
* allocated with malloc() or vice versa. Since libxml might be used by
* loadable modules, eg libperl, our only safe choices are to change the
* functions at postmaster/backend launch or not at all. Since we'd rather
* not activate libxml in sessions that might never use it, the latter choice
* is the preferred one. However, for debugging purposes it can be awfully
* handy to constrain libxml's allocations to be done in a specific palloc
* context, where they're easy to track. Therefore there is code here that
* can be enabled in debug builds to redirect libxml's allocations into a
* special context LibxmlContext. It's not recommended to turn this on in
* a production build because of the possibility of bad interactions with
* external modules.
*/
/* #define USE_LIBXMLCONTEXT */

Then if you look at xpath.c in contrib/xml2 you notice that it's doing
exactly the thing that the core module says it's unreliable: using
palloc and friends in xmlMemSetup. So to fix the bug what's needed is
that the xmlMemSetup call in contrib is removed altogether, and all
memory is tracked and released by hand. It's rather tedious, and it's
also difficult to plug all resulting memory leaks. But AFAIUI doing
that would fix (some of?) the crashes. Not sure if your crash is in
this category.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-02-18 14:12:58 Re: A thought: should we run pgindent now?
Previous Message Heikki Linnakangas 2010-02-18 12:46:46 Re: Streaming replication on win32, still broken