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
Re: BUG #3860: xpath crashes backend when is querying xmlagg result |
Список | 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 по дате отправления: