Tom Lane escribió:
> Alvaro Herrera <alvherre@commandprompt.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.
Yeah, we can free it with xmlCleanupParser. Too blunt an instrument,
perhaps?
> > 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.
Yeah, apparently it doesn't work very well.
> 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.
I guess the problem is that the objects can contain pointers and we have
no way of following those to copy them. Perhaps we can make it use
malloc, let it create the object, switch to palloc, create a clone,
revert to malloc, free the original.
What problem you have with it having its own memory context? I don't
think it has any particular disadvantage.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support