Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.

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                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group