Re: BUG #3860: xpath crashes backend when is querying xmlagg result - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3860: xpath crashes backend when is querying xmlagg result
Date
Msg-id 12425.1199906569@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #3860: xpath crashes backend when is querying xmlagg result  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: BUG #3860: xpath crashes backend when is querying xmlagg result
Re: BUG #3860: xpath crashes backend when is querying xmlagg result
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> What problem you have with it having its own memory context?  I don't
> think it has any particular disadvantage.

I don't object to that per se; I'm just saying it doesn't do much to
fix the problem.  The difficulty we've got here ultimately comes down
to separating long-lived objects from not-long-lived ones.  It seems
libxml doesn't have adequate controls to let us do that.  If we run
libxml in a context we don't ever reset, then we leak memory if an
error occurs while we're fooling around with a function result.
If we do reset the context, then we've got exactly this problem again
of possibly deleting objects that libxml thinks are still there.

We might be able to compromise by only resetting the context after
an error, but this is still only possible if we have a way to make
libxml let go of *all* pointers to alloc'd objects.  I don't understand
your comment that xmlCleanupParser solves it --- we call that already,
and it doesn't seem to be preventing the problem.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: BUG #3865: ERROR: failed to build any 8-way joins
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #3860: xpath crashes backend when is querying xmlagg result