From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Sokolov Yura <funny(dot)falcon(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: BUG #3860: xpath crashes backend when is querying xmlagg result |
Date: | 2008-01-09 19:22:49 |
Message-ID: | 12425.1199906569@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Kaltenbrunner | 2008-01-09 19:30:33 | Re: BUG #3865: ERROR: failed to build any 8-way joins |
Previous Message | Oleg Kharin | 2008-01-09 18:07:55 | BUG #3865: ERROR: failed to build any 8-way joins |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-09 19:54:55 | Re: OUTER JOIN performance regression remains in 8.3beta4 |
Previous Message | Gregory Stark | 2008-01-09 19:05:07 | Re: OUTER JOIN performance regression remains in 8.3beta4 |