pá 8. 3. 2019 v 13:20 odesílatel Alvaro Herrera <alvhe...@2ndquadrant.com> napsal:
> On 2019-Mar-08, Pavel Stehule wrote: > > > looks like error in xmlXPathCompiledEval function, that produce little > bit > > broken result for XML_DOCUMENT_NODE type. I hadn't this problem with > > libxml2 2.7.6 64bit, but I seen this issue on same version on 32bit. > > > > Currently I had not fresh 32 bit system to check it. > > > > I found a workaround - in this case copy (and release xmlNode) is not > > necessary. > > > > please, apply attached patch. > > Wow :-( At this point I'm wondering if this should be put in back > branches as well ... I mean, distill part of commit 251cf2e27bec that > doesn't affect the behavior of text nodes, and put it on all branches > together with your fix? > The problem is just for case result: XML_DOCUMENT_TYPE, target XML. For this case the previously used transformation doesn't work. Is not problem to detect this situation. The content field has -1 instead 0. Originally there was inverted logic, so xmlCopyNode and xmlFreeNode was not used for XML_DOCUMENT_TYPE, and then we didn't hit this bug. > Another thought: should we refuse to work on known-broken libxml2 > versions? Seems like this bug could affect other parts of code too -- I > see that xmlXPathCompiledEval() is called in file places (including two > in contrib/xml2). > > Third thought: an alternative might be to create a wrapper for > xmlXPathCompiledEval that detects NULL content and fills in a pointer > that xmlFreeNode can free. > > > -- > Álvaro Herrera https://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >