Re: BUG #3860: xpath crashes backend when is querying xmlagg result

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #3860: xpath crashes backend when is querying xmlagg result
Дата
Msg-id 12425.1199906569@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #3860: xpath crashes backend when is querying xmlagg result  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: BUG #3860: xpath crashes backend when is querying xmlagg result  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: BUG #3860: xpath crashes backend when is querying xmlagg result  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: BUG #3865: ERROR: failed to build any 8-way joins
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #3860: xpath crashes backend when is querying xmlagg result