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

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> What's happening is that libxml encoding handler table is being
> allocated in an ExprContext which apparently is too short-lived.

> I'm not seeing very well how to handle this -- one idea would be to
> manually call xmlInitCharEncodingHandlers (which is public but supposed
> to be called internally by libxml) with a longer-lived context, but I
> wonder whether there's some other initialization that will come bite us.

Ugh. This seems like about the worst-case scenario: we don't know when
libxml chooses to allocate or free this data structure, and apparently
we have no way to force it to be freed.

> Another idea would be to initialize and then destroy the libxml state
> separately for each expression, which perhaps doesn't really work at
> all.

That's what we're trying to do now, I thought.

> Perhaps a better idea is to create a separate LibxmlContext memcxt,
> child of QueryContext, and have xml_palloc etc always use that. That
> way it won't be reset between calls. It probably also means we could
> wire xml reset to transaction abort, making it a bit simpler.

Might as well go back to letting it use malloc :-(.

I actually don't see a problem with letting it use malloc for stuff that
it is going to manage for itself. I guess the problem comes with
transient return values of libxml functions; we'd want to explicitly
move those into palloc-based storage and then free() them.

This looks like a rather large rewrite though. Peter, have you any
better ideas?

regards, tom lane