Re: [PATCH] Add native windows on arm64 support

Michael Paquier <michael@paquier.xyz> writes:
> 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?

I'm not sure.  I dug into this enough to find that the output from
this query is generated in xml.c lines 4635ff:

                    /* Concatenate serialized values */
                    initStringInfo(&str);
                    for (int i = 0; i < count; i++)
                    {
                        textstr =
                            xml_xmlnodetoxmltype(xpathobj->nodesetval->nodeTab[i],
                                                 xtCxt->xmlerrcxt);

                        appendStringInfoText(&str, textstr);
                    }
                    cstr = str.data;

So evidently, the problem occurs because the elements of the
nodesetval->nodeTab[] array are in a different order than we expect.

I looked into <xpath.h> and found the definition of the "nodesetval"
struct, and the comments are eye-opening to say the least:

/*
 * A node-set (an unordered collection of nodes without duplicates).
 */
typedef struct _xmlNodeSet xmlNodeSet;
typedef xmlNodeSet *xmlNodeSetPtr;
struct _xmlNodeSet {
    int nodeNr;			/* number of nodes in the set */
    int nodeMax;		/* size of the array as allocated */
    xmlNodePtr *nodeTab;	/* array of nodes in no particular order */
    /* @@ with_ns to check wether namespace nodes should be looked at @@ */
};

It seems like maybe we're relying on an ordering we should not.
Yet surely the ordering of the pieces of this output is meaningful?
Are we using the wrong libxml API to create this result?

Anyway, I'm now suspicious that we've accidentally exposed a logic
bug in the XMLTABLE code, rather than anything wrong with the
ASLR stuff.

			regards, tom lane