Re: [PATCH] Add native windows on arm64 support
От | Michael Paquier |
---|---|
Тема | Re: [PATCH] Add native windows on arm64 support |
Дата | |
Msg-id | Yw6oBJgXWnJsy3SE@paquier.xyz обсуждение исходный текст |
Ответ на | Re: [PATCH] Add native windows on arm64 support (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [PATCH] Add native windows on arm64 support
|
Список | pgsql-hackers |
On Wed, Aug 31, 2022 at 08:36:01AM +0900, Michael Paquier wrote: > There have been more failures, always switching the input from > "pre<!--c1--><?pi arg?><![CDATA[&ent1]]><n2>&deep</n2>post" > to "pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&deep</n2>post". > > Using a PATH of node() influences the output. I am not verse unto > XMLTABLE, but could it be an issue where each node is parsed and we > have something like a qsort() applied on the pointer addresses for > each part or something like that, causing the output to become > unstable? Hmm. I think that I may have an idea here after looking at our xml.c and xpath.c in libxml2/. From what I understand, we process the PATH through XmlTableGetValue() that builds a XML node path in xmlXPathCompiledEval(). The interesting part comes from libxml2's xmlXPathCompiledEvalInternal(), where I think we don't apply a sort on the contents generated. Hence, I am wondering if the solution here would be to do one xmlXPathNodeSetSort(xpathobj->nodesetval) after compiling the path with xmlXPathCompiledEval() in XmlTableGetValue(). This should ensure that the items are ordered even if ASLR mixes if the pointer positions. A complete solution would involve more code paths, but we'd need only one change in XmlTableGetValue() for the current regression tests to work. I don't have an environment where I can reproduce that, so that would be up to the buildfarm to stress this solution.. Thoughts? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: