Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 31 Aug 2022 09:15:00 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Niyas Sait <niyas.sait@linaro.org>,
	Thomas Munro <thomas.munro@gmail.com>,
	Julien Rouhaud <rjuju123@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Add native windows on arm64 support
Message-ID: <Yw6oBJgXWnJsy3SE@paquier.xyz>
References: <2655387.1661695793@sss.pgh.pa.us>
 <20220828154154.4vk6lymdbvx7hnhc@awork3.anarazel.de>
 <2679975.1661701879@sss.pgh.pa.us>
 <YwwSdACDiHqtPkMA@paquier.xyz>
 <Yw1QVptf33FMZw6n@paquier.xyz>
 <3426682.1661817511@sss.pgh.pa.us>
 <20220830003356.yl7ok3elemonrclo@awork3.anarazel.de>
 <Yw1pZ8X3rG/i8TFn@paquier.xyz>
 <3479390.1661824810@sss.pgh.pa.us>
 <Yw6e4dA4mmusdEsx@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="5Gj6Cjz3ADZRdYTr"
Content-Disposition: inline
In-Reply-To: <Yw6e4dA4mmusdEsx@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/Yw6oBJgXWnJsy3SE%40paquier.xyz>
Precedence: bulk


--5Gj6Cjz3ADZRdYTr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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>&amp;deep</n2>post"
> to "pre<?pi arg?><![CDATA[&ent1]]><!--c1--><n2>&amp;deep</n2>post".
>=20
> 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

--5Gj6Cjz3ADZRdYTr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmMOqAQACgkQnvQgOdby
QH3q+A/+O3/TRs+0DkuV/fYD4vj/l1Xc0kfCRfTiprBqq6Bd7t4VmYIwVVld3/0j
pZhJgSq0gJsDQ5VWxRGs9LPUcQK8t5q+AapJoQQehREANGSzN8tCGsNwupCULYcW
r4UYMuUsvJG1/SGY7ijvyrwlZA80Prwt+jrdEHkNOkuzufG2Kwmpgvx2Wo7q5vTl
lCg6IyUKyOVcPdFHUoVbh7eo3TauekPV54kB2kWtQx7LFz6n5jy3PGbLce4Czmrg
Th7aupJNxhNr5YN5gHcqek6OVs+X2BwaHbOm8yzz4wvJAqc/Xp7M80QqxTOEKRac
YKNBeToPwdwqoO9f0RI4N9ifDwBQ5xGrIq4p3B8VrGSZHF8QzWLLXuYwEIl1fK59
JBWEQcqza/G1G6iQJ922AAW+Q+i8B+II2F8daHab0j0NbRZDSQQgNL6IQp1bKJng
//5tjAkf5fzZXEsSfXYmjEcSbcIbi/XKQqX9jMWZY+rr/1Bwxe6XS0mm3AtZiPDW
Vkpne3G/GpnB1yaEePg99VGyImmhDRQhV6HMTDZUSpX38XpmZe54zfjYU9FAd19L
a9gwUX2VzWiWaY4ek8h+/Nx//5CMTwgLkdde1XLBHxJnCkRGDYfNbt3MeT+03lNE
rgims94xb+zUGA7YPVRXx0cvrcK0FlriYQX2qormlx/5PMSkraY=
=YvyK
-----END PGP SIGNATURE-----

--5Gj6Cjz3ADZRdYTr--