|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, Niyas Sait <niyas(dot)sait(at)linaro(dot)org>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, robhenry(at)microsoft(dot)com, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|Subject:||Re: [PATCH] Add native windows on arm64 support|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andres Freund <andres(at)anarazel(dot)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.
regards, tom lane
|Next Message||Andres Freund||2023-05-08 20:28:03||Re: base backup vs. concurrent truncation|
|Previous Message||Andres Freund||2023-05-08 19:58:22||Re: issue with meson builds on msys2|