Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oTBGf-0000im-5p for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Aug 2022 00:07:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oTBGd-0007kD-8A for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Aug 2022 00:07:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oTBGc-0007jx-VH for pgsql-hackers@lists.postgresql.org; Wed, 31 Aug 2022 00:07:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oTBGY-0005QD-Jl for pgsql-hackers@lists.postgresql.org; Wed, 31 Aug 2022 00:07:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 27V07Rxl3882926; Tue, 30 Aug 2022 20:07:27 -0400 From: Tom Lane To: Michael Paquier cc: Andres Freund , Niyas Sait , Thomas Munro , Julien Rouhaud , PostgreSQL Hackers Subject: Re: [PATCH] Add native windows on arm64 support In-reply-to: References: <2655387.1661695793@sss.pgh.pa.us> <20220828154154.4vk6lymdbvx7hnhc@awork3.anarazel.de> <2679975.1661701879@sss.pgh.pa.us> <3426682.1661817511@sss.pgh.pa.us> <20220830003356.yl7ok3elemonrclo@awork3.anarazel.de> <3479390.1661824810@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Wed, 31 Aug 2022 08:36:01 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3882924.1661904447.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2022 20:07:27 -0400 Message-ID: <3882925.1661904447@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier 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 =3D 0; i < count; i++) { textstr =3D xml_xmlnodetoxmltype(xpathobj->nodesetval->nod= eTab[i], xtCxt->xmlerrcxt); appendStringInfoText(&str, textstr); } cstr =3D 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 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