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 1pwjoM-0005SQ-LW for pgsql-hackers@arkaria.postgresql.org; Wed, 10 May 2023 13:24:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pwjoL-0003RC-Ir for pgsql-hackers@arkaria.postgresql.org; Wed, 10 May 2023 13:24:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pwjoL-0003R1-5V for pgsql-hackers@lists.postgresql.org; Wed, 10 May 2023 13:24:53 +0000 Received: from relay2-d.mail.gandi.net ([2001:4b98:dc4:8::222]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pwjoH-001ZSN-0L for pgsql-hackers@lists.postgresql.org; Wed, 10 May 2023 13:24:51 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id C34E54000B; Wed, 10 May 2023 13:24:40 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------T0JOZt0soUN9c8bs2Y4Pj3u7" Message-ID: <00b0804c-3e5d-22b5-c7dd-3efe6d43d78d@dunslane.net> Date: Wed, 10 May 2023 09:24:39 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: en-US To: Tom Lane , Andres Freund Cc: Michael Paquier , Niyas Sait , Ian Lawrence Barwick , Thomas Munro , Julien Rouhaud , PostgreSQL Hackers , robhenry@microsoft.com, "Jonathan S. Katz" , Alvaro Herrera , Amit Kapila References: <20221205181449.47mhosidtmotemdl@awork3.anarazel.de> <6cfaaf3c-7fb5-51c8-92cf-ceac6303ef66@linaro.org> <20230117225131.jeptl4axjlbk5glz@awork3.anarazel.de> <44f6c1b6-d712-b69b-82f2-8c525f59aeff@linaro.org> <3864856.1683347740@sss.pgh.pa.us> <20230508191731.mtt3mpgrr6v2br7t@awork3.anarazel.de> <461478.1683575921@sss.pgh.pa.us> From: Andrew Dunstan Subject: Re: [PATCH] Add native windows on arm64 support In-Reply-To: <461478.1683575921@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------T0JOZt0soUN9c8bs2Y4Pj3u7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-05-08 Mo 15:58, Tom Lane wrote: > Andres Freund writes: >> I don't really have feelings either way - but haven't we gone further and even >> backpatched things like spinlock support for new arches in the past? > Mmmm ... don't really think those cases were comparable. We weren't > adding support for a whole new OS. Now, you might argue that Windows > on arm64 will be just like Windows on x86_64, but I think the jury > is still out on that. Microsoft was so Intel-only for so many years > that I bet they've had to change quite a bit to make it go on ARM. > > Also, the cases of back-patched spinlock support that I can find > in the last few years were pretty low-risk. I'll grant that > c32fcac56 was a bit blue-sky because hardly anybody had RISC-V > at that point, but by the same token anybody relying on it at the > time would be dealing with a beta-grade OS too. On the other hand, > 1c72d82c2 was immediately testable in the buildfarm, and f3bd00c01 > was importing code already verified by our OpenBSD packagers. > > As I said upthread, this seems like something to put in at the > beginning of a dev cycle, not post-feature-freeze. > We will definitely want buildfarm support. I don't have such a machine and am not likely to have one any time soon. I do run drongo and fairywren on an EC2 instance, but AWS doesn't seem to have support for Windows on ARM. Maybe it's available on Azure (maybe then some of our colleagues working at Microsoft could arrange such a beast for me to set up potential buildfarm animal, or else run one themselves.) cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com --------------T0JOZt0soUN9c8bs2Y4Pj3u7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 2023-05-08 Mo 15:58, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:

I don't really have feelings either way - but haven't we gone further and even
backpatched things like spinlock support for new arches in the past?

Mmmm ... don't really think those cases were comparable.  We weren't
adding support for a whole new OS.  Now, you might argue that Windows
on arm64 will be just like Windows on x86_64, but I think the jury
is still out on that.  Microsoft was so Intel-only for so many years
that I bet they've had to change quite a bit to make it go on ARM.

Also, the cases of back-patched spinlock support that I can find
in the last few years were pretty low-risk.  I'll grant that
c32fcac56 was a bit blue-sky because hardly anybody had RISC-V
at that point, but by the same token anybody relying on it at the
time would be dealing with a beta-grade OS too.  On the other hand,
1c72d82c2 was immediately testable in the buildfarm, and f3bd00c01
was importing code already verified by our OpenBSD packagers.

As I said upthread, this seems like something to put in at the
beginning of a dev cycle, not post-feature-freeze.


We will definitely want buildfarm support. I don't have such a machine and am not likely to have one any time soon. I do run drongo and fairywren on an EC2 instance, but AWS doesn't seem to have support for Windows on ARM. Maybe it's available on Azure (maybe then some of our colleagues working at Microsoft could arrange such a beast for me to set up potential buildfarm animal, or else run one themselves.)



cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com
--------------T0JOZt0soUN9c8bs2Y4Pj3u7--