public inbox for [email protected]
help / color / mirror / Atom feedRe: [PATCH] Add native windows on arm64 support
60+ messages / 11 participants
[nested] [flat]
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-06 03:09 Michael Paquier <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2023-05-06 03:09 UTC (permalink / raw)
To: Niyas Sait <[email protected]>; +Cc: Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Tue, May 02, 2023 at 08:51:09AM +0100, Niyas Sait wrote:
> I've attached a new version (v8) to fix the above indentation issue.
>
> Could someone please help with the review ?
Seeing how simple this has become, I would be really tempted to get
that applied, especially if there's a buildfarm machine able to follow
up.. On the one hand, we are in a stability period for v16, so it may
not be the best moment ever. On the other hand, waiting one more year
sounds like a waste for a patch that just adds new code paths.
RMT members, any thoughts?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-06 04:35 Tom Lane <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 2 replies; 60+ messages in thread
From: Tom Lane @ 2023-05-06 04:35 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Niyas Sait <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
Michael Paquier <[email protected]> writes:
> Seeing how simple this has become, I would be really tempted to get
> that applied, especially if there's a buildfarm machine able to follow
> up.. On the one hand, we are in a stability period for v16, so it may
> not be the best moment ever. On the other hand, waiting one more year
> sounds like a waste for a patch that just adds new code paths.
Indeed, there's not much in this patch ... but it's impossible to see
how "run on an entirely new platform" isn't a new feature. Moreover,
it's a platform that very few of us will have any ability to support
or debug for. I can't see how it's a good idea to shove this in
post-feature-freeze. Let's plan to push it in when v17 opens.
regards, tom lane
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-07 00:37 Michael Paquier <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 60+ messages in thread
From: Michael Paquier @ 2023-05-07 00:37 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Niyas Sait <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Sat, May 06, 2023 at 12:35:40AM -0400, Tom Lane wrote:
> Indeed, there's not much in this patch ... but it's impossible to see
> how "run on an entirely new platform" isn't a new feature. Moreover,
> it's a platform that very few of us will have any ability to support
> or debug for. I can't see how it's a good idea to shove this in
> post-feature-freeze. Let's plan to push it in when v17 opens.
Fine by me. I have added an entry in the CF app to remember about
this stuff as there was nothing present yet:
https://commitfest.postgresql.org/43/4309/
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-08 19:17 Andres Freund <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Andres Freund @ 2023-05-08 19:17 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
Hi,
On 2023-05-06 00:35:40 -0400, Tom Lane wrote:
> Michael Paquier <[email protected]> writes:
> > Seeing how simple this has become, I would be really tempted to get
> > that applied, especially if there's a buildfarm machine able to follow
> > up.. On the one hand, we are in a stability period for v16, so it may
> > not be the best moment ever. On the other hand, waiting one more year
> > sounds like a waste for a patch that just adds new code paths.
>
> Indeed, there's not much in this patch ... but it's impossible to see
> how "run on an entirely new platform" isn't a new feature. Moreover,
> it's a platform that very few of us will have any ability to support
> or debug for. I can't see how it's a good idea to shove this in
> post-feature-freeze. Let's plan to push it in when v17 opens.
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?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-08 19:58 Tom Lane <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Tom Lane @ 2023-05-08 19:58 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
Andres Freund <[email protected]> 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
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-10 13:24 Andrew Dunstan <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2023-05-10 13:24 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On 2023-05-08 Mo 15:58, Tom Lane wrote:
> Andres Freund<[email protected]> 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
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-10 23:34 Michael Paquier <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 2 replies; 60+ messages in thread
From: Michael Paquier @ 2023-05-10 23:34 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:
> 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.)
Unfortunately AWS does not offer ARM on Windows with an EC2, that's
something I have also looked at setting up :/
Anyway, Niyat has mentioned me that he was working on that, but it
seems that it was off-list. Niyat, could you confirm this part?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-11 00:17 Thomas Munro <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Thomas Munro @ 2023-05-11 00:17 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Thu, May 11, 2023 at 11:34 AM Michael Paquier <[email protected]> wrote:
> On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:
> > 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.)
>
> Unfortunately AWS does not offer ARM on Windows with an EC2, that's
> something I have also looked at setting up :/
Azure does have an image "Microsoft Windows 11 Preview arm64" to run
on Ampere CPUs, which says it's a pre-release version intended for
validation, which sounds approximately like what we want. I will try
to find out more.
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-11 04:19 Michael Paquier <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2023-05-11 04:19 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Thu, May 11, 2023 at 12:17:25PM +1200, Thomas Munro wrote:
> Azure does have an image "Microsoft Windows 11 Preview arm64" to run
> on Ampere CPUs, which says it's a pre-release version intended for
> validation, which sounds approximately like what we want. I will try
> to find out more.
Interesting. Thanks for mentioning it.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-05-11 07:57 Niyas Sait <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Niyas Sait @ 2023-05-11 07:57 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On 11/05/2023 00:34, Michael Paquier wrote:
> On Wed, May 10, 2023 at 09:24:39AM -0400, Andrew Dunstan wrote:
>> 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.)
> Unfortunately AWS does not offer ARM on Windows with an EC2, that's
> something I have also looked at setting up :/
>
> Anyway, Niyat has mentioned me that he was working on that, but it
> seems that it was off-list. Niyat, could you confirm this part?
> --
> Michael
If we have Azure VM credits, we could use that to deploy buildfarm machines.
Otherwise, I can try to allocate a machine from Linaro Windows Lab for
the buildbot.
--
Niyas
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-06-14 12:25 Niyas Sait <[email protected]>
parent: Niyas Sait <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Niyas Sait @ 2023-06-14 12:25 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; [email protected]; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
Hello,
Just wanted to give a heads up that I am moving to a new role outside
Linaro and as a result wouldn't be able to continue contributing.
Anthony Roberts from Linaro is going to support the enablement work.
--
Niyas
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-07-04 07:34 Michael Paquier <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 0 replies; 60+ messages in thread
From: Michael Paquier @ 2023-07-04 07:34 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Niyas Sait <[email protected]>; Ian Lawrence Barwick <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Thu, May 11, 2023 at 01:19:54PM +0900, Michael Paquier wrote:
> On Thu, May 11, 2023 at 12:17:25PM +1200, Thomas Munro wrote:
>> Azure does have an image "Microsoft Windows 11 Preview arm64" to run
>> on Ampere CPUs, which says it's a pre-release version intended for
>> validation, which sounds approximately like what we want. I will try
>> to find out more.
>
> Interesting. Thanks for mentioning it.
Now that v17 is open, I was looking at v8 posted at [1] and I don't
have much more to add about it. The problem about the lack of
buildfarm machine is still annoying, but I don't see a reason not to
move forward and let people play with this stuff on HEAD. At least
that would be progress. Any thoughts?
Thomas, what's the state of ARM support for Windows on Azure? Is that
still in preview?
[1]: https://www.postgresql.org/message-id/dbee741f-b9b7-a0d5-1b1b-f9b532bb6f56%40linaro.org
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-17 08:41 Anthony Roberts <[email protected]>
parent: Niyas Sait <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Anthony Roberts @ 2023-08-17 08:41 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
Hi All,
Just following up on this, has there been any movement?
I did see another message go into the thread here with no reply:
https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz
Thanks,
Anthony
On 14/06/2023 13:25, Niyas Sait wrote:
> Hello,
>
> Just wanted to give a heads up that I am moving to a new role outside
> Linaro and as a result wouldn't be able to continue contributing.
>
> Anthony Roberts from Linaro is going to support the enablement work.
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-17 22:28 Michael Paquier <[email protected]>
parent: Anthony Roberts <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2023-08-17 22:28 UTC (permalink / raw)
To: Anthony Roberts <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Thu, Aug 17, 2023 at 09:41:44AM +0100, Anthony Roberts wrote:
> Just following up on this, has there been any movement?
>
> I did see another message go into the thread here with no reply:
> https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz
I don't have an environment to test the patch, but I don't object to
it per se. However, I don't really want to move forward completely
blindly as well in the long-term.
As mentioned to Niyas, could it be possible to provide to the
community a buildfarm machine that would be able to test this
environment? I am not sure what's your status on that. Perhaps this
is already set up and you are just waiting for the patch to be merged?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-25 09:40 Anthony Roberts <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 2 replies; 60+ messages in thread
From: Anthony Roberts @ 2023-08-25 09:40 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
Hi,
Which of these are you looking for us to provide:
* A machine for you to directly access (via a VPN)
* A machine we just run a worker script on that automatically picks up
the builds as required
* Us to do downstream CI
All are possible, but preferably not option 1, as it would mean straight
up pulling out a machine from our build farm, and it has to go through
all sorts of approvals internally. If it's the only way forward I can
kick it up the chain though.
Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake,
3 - OpenSSL)
Thanks,
Anthony
On 17/08/2023 23:28, Michael Paquier wrote:
> On Thu, Aug 17, 2023 at 09:41:44AM +0100, Anthony Roberts wrote:
>> Just following up on this, has there been any movement?
>>
>> I did see another message go into the thread here with no reply:
>> https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz
> I don't have an environment to test the patch, but I don't object to
> it per se. However, I don't really want to move forward completely
> blindly as well in the long-term.
>
> As mentioned to Niyas, could it be possible to provide to the
> community a buildfarm machine that would be able to test this
> environment? I am not sure what's your status on that. Perhaps this
> is already set up and you are just waiting for the patch to be merged?
> --
> Michael
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-25 10:17 Michael Paquier <[email protected]>
parent: Anthony Roberts <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2023-08-25 10:17 UTC (permalink / raw)
To: Anthony Roberts <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:
> Which of these are you looking for us to provide:
>
> * A machine for you to directly access (via a VPN)
> * A machine we just run a worker script on that automatically picks up the
> builds as required
> * Us to do downstream CI
>
> All are possible, but preferably not option 1, as it would mean straight up
> pulling out a machine from our build farm, and it has to go through all
> sorts of approvals internally. If it's the only way forward I can kick it up
> the chain though.
>
> Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake, 3 -
> OpenSSL)
The community has its own CI facility. Here is a link of how to set
up a machine:
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
And all the results are published by the maintainers of the machines
on a periodic basis where the buildfarm client code is set:
https://buildfarm.postgresql.org/cgi-bin/show_status.pl
The final result would be for you to maintain the machine so as we are
able to see if anything breaks with it. Adding extra dependencies to
the build like OpenSSL would be nice, but based on the contents of the
patch to add this port that does not seem mandatory to me, either.
Once the machine is ready, you will need to request a buildfarm
machine name and a key to be able to begin publishing the reports of
the builds to the community buildfarm. Once the machine is ready to
go, just let me know and I'd be OK to merge the patch (I still want to
do a final review of it in case I've missed something, but I can move
on with that before the buildfarm machine is set up).
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../ZOh%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-25 10:34 Anthony Roberts <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Anthony Roberts @ 2023-08-25 10:34 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
Thanks for the link - that looks basically the same as what we do for
CMake (option 2), so should be relatively easy.
I will have a chat to relevant people about setting a machine up
properly for it.
Thanks,
Anthony
On 25/08/2023 11:17, Michael Paquier wrote:
> On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:
>> Which of these are you looking for us to provide:
>>
>> * A machine for you to directly access (via a VPN)
>> * A machine we just run a worker script on that automatically picks up the
>> builds as required
>> * Us to do downstream CI
>>
>> All are possible, but preferably not option 1, as it would mean straight up
>> pulling out a machine from our build farm, and it has to go through all
>> sorts of approvals internally. If it's the only way forward I can kick it up
>> the chain though.
>>
>> Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake, 3 -
>> OpenSSL)
> The community has its own CI facility. Here is a link of how to set
> up a machine:
> https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
>
> And all the results are published by the maintainers of the machines
> on a periodic basis where the buildfarm client code is set:
> https://buildfarm.postgresql.org/cgi-bin/show_status.pl
>
> The final result would be for you to maintain the machine so as we are
> able to see if anything breaks with it. Adding extra dependencies to
> the build like OpenSSL would be nice, but based on the contents of the
> patch to add this port that does not seem mandatory to me, either.
>
> Once the machine is ready, you will need to request a buildfarm
> machine name and a key to be able to begin publishing the reports of
> the builds to the community buildfarm. Once the machine is ready to
> go, just let me know and I'd be OK to merge the patch (I still want to
> do a final review of it in case I've missed something, but I can move
> on with that before the buildfarm machine is set up).
> --
> Michael
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-25 11:48 Daniel Gustafsson <[email protected]>
parent: Anthony Roberts <[email protected]>
1 sibling, 0 replies; 60+ messages in thread
From: Daniel Gustafsson @ 2023-08-25 11:48 UTC (permalink / raw)
To: Anthony Roberts <[email protected]>; +Cc: Michael Paquier <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>
> On 25 Aug 2023, at 11:40, Anthony Roberts <[email protected]> wrote:
> * A machine for you to directly access (via a VPN)
That could be very helpful to provide to developers who are trying to debug
very wicked bugs which requires access for analysis. Such things are on a case
by case basis of course at your discretion, but it would most likely be very
appreciated when/if the need exists.
> * A machine we just run a worker script on that automatically picks up the builds as required
This sounds like what we have for the buildfarm, where machines independently
builds the branches from the Git repo by using the buildfarm client as worker.
> * Us to do downstream CI
This sounds like the CFBot, where we (currently) use Cirrus with our own
workers for building and testing the patches which are being worked on.
http://cfbot.cputube.org/
Both the two latter options are very helpful for the community, and serve two
distincly different purposes. Option 2 is required for a platform to be
considered supported whereas option 3 assists developers in being proactive
rather than just reactive.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-30 15:12 Anthony Roberts <[email protected]>
parent: Anthony Roberts <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Anthony Roberts @ 2023-08-30 15:12 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
Hi,
Just a follow-up: having spoken to the relevant people, sadly, right now,
we do not have the capacity to be pulling machines out of our day-to-day CI
tasks to dedicate to specific projects.
I can, however, offer a few alternatives:
1. If you have capacity on your linux x64 machines, it is possible to
emulate WoA, and run tests that way:
https://www.linaro.org/blog/emulate-windows-on-arm/
This is something that works well for projects that we have contributed it
to (ie, sse2neon uses it via github actions) - if you run into any issues
with this, we are able to try and fix them on our side, as likely more than
postgres would benefit.
2. If there is any scope for it on your side at all, a Samsung Galaxy Book
Go 14" can be had from ebay for ~£140.
Understandably, this might not be an option for you.
If it helps, if this is merged, we do have the possibility of running our
own downstream CI builds nightly for the tip of your main branch here:
https://gitlab.com/Linaro/windowsonarm/nightly
This is something we do for a few projects that do not have full upstream
CI.
Thanks,
Anthony
On Fri, 25 Aug 2023 at 11:34, Anthony Roberts <[email protected]>
wrote:
> Thanks for the link - that looks basically the same as what we do for
> CMake (option 2), so should be relatively easy.
>
> I will have a chat to relevant people about setting a machine up
> properly for it.
>
> Thanks,
> Anthony
>
> On 25/08/2023 11:17, Michael Paquier wrote:
> > On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:
> >> Which of these are you looking for us to provide:
> >>
> >> * A machine for you to directly access (via a VPN)
> >> * A machine we just run a worker script on that automatically picks up
> the
> >> builds as required
> >> * Us to do downstream CI
> >>
> >> All are possible, but preferably not option 1, as it would mean
> straight up
> >> pulling out a machine from our build farm, and it has to go through all
> >> sorts of approvals internally. If it's the only way forward I can kick
> it up
> >> the chain though.
> >>
> >> Option 2 and 3 are ones we do for various other projects (ie. 2 -
> CMake, 3 -
> >> OpenSSL)
> > The community has its own CI facility. Here is a link of how to set
> > up a machine:
> > https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
> >
> > And all the results are published by the maintainers of the machines
> > on a periodic basis where the buildfarm client code is set:
> > https://buildfarm.postgresql.org/cgi-bin/show_status.pl
> >
> > The final result would be for you to maintain the machine so as we are
> > able to see if anything breaks with it. Adding extra dependencies to
> > the build like OpenSSL would be nice, but based on the contents of the
> > patch to add this port that does not seem mandatory to me, either.
> >
> > Once the machine is ready, you will need to request a buildfarm
> > machine name and a key to be able to begin publishing the reports of
> > the builds to the community buildfarm. Once the machine is ready to
> > go, just let me know and I'd be OK to merge the patch (I still want to
> > do a final review of it in case I've missed something, but I can move
> > on with that before the buildfarm machine is set up).
> > --
> > Michael
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-31 04:22 Michael Paquier <[email protected]>
parent: Anthony Roberts <[email protected]>
0 siblings, 2 replies; 60+ messages in thread
From: Michael Paquier @ 2023-08-31 04:22 UTC (permalink / raw)
To: Anthony Roberts <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
On Wed, Aug 30, 2023 at 04:12:16PM +0100, Anthony Roberts wrote:
> Just a follow-up: having spoken to the relevant people, sadly, right now,
> we do not have the capacity to be pulling machines out of our day-to-day CI
> tasks to dedicate to specific projects.
Okay, thanks for letting us know.
> I can, however, offer a few alternatives:
>
> 1. If you have capacity on your linux x64 machines, it is possible to
> emulate WoA, and run tests that way:
> https://www.linaro.org/blog/emulate-windows-on-arm/
> This is something that works well for projects that we have contributed it
> to (ie, sse2neon uses it via github actions) - if you run into any issues
> with this, we are able to try and fix them on our side, as likely more than
> postgres would benefit.
>
> 2. If there is any scope for it on your side at all, a Samsung Galaxy Book
> Go 14" can be had from ebay for ~£140.
> Understandably, this might not be an option for you.
>
> If it helps, if this is merged, we do have the possibility of running our
> own downstream CI builds nightly for the tip of your main branch here:
> https://gitlab.com/Linaro/windowsonarm/nightly
> This is something we do for a few projects that do not have full upstream
> CI.
Honestly, I am not sure how to proceed here. Having something in the
buildfarm is necessary IMO, because this is the central place that
community members look at when it comes to monitoring the stability of
a patch committed.
Any opinions from the others?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-31 04:44 Tom Lane <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Tom Lane @ 2023-08-31 04:44 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
Michael Paquier <[email protected]> writes:
> On Wed, Aug 30, 2023 at 04:12:16PM +0100, Anthony Roberts wrote:
>> Just a follow-up: having spoken to the relevant people, sadly, right now,
>> we do not have the capacity to be pulling machines out of our day-to-day CI
>> tasks to dedicate to specific projects.
> Okay, thanks for letting us know.
Too bad.
> Honestly, I am not sure how to proceed here. Having something in the
> buildfarm is necessary IMO, because this is the central place that
> community members look at when it comes to monitoring the stability of
> a patch committed.
> Any opinions from the others?
I agree. I'm really uncomfortable with claiming support for
Windows-on-ARM if we don't have a buildfarm member testing it.
For other platforms that have a track record of multiple
hardware support, it might not be a stretch ... but Windows was
so resolutely Intel-only for so long that "it works on ARM" is
a proposition that I won't trust without hard evidence. There
are too many bits of that system that might not have gotten the
word yet, or at least not gotten sufficient testing.
My vote for this is we don't commit without a buildfarm member.
(As a comparison point, I'd still be unsure about our support
for macOS-on-ARM if we didn't have buildfarm support for that.
That exists, and is being paid for out of my own pocket.
I do not have much sympathy for a corporation that claims
it can't afford to support one measly buildfarm animal.)
regards, tom lane
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-31 04:57 Thomas Munro <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Thomas Munro @ 2023-08-31 04:57 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
On Thu, Aug 31, 2023 at 4:22 PM Michael Paquier <[email protected]> wrote:
> Honestly, I am not sure how to proceed here. Having something in the
> buildfarm is necessary IMO, because this is the central place that
> community members look at when it comes to monitoring the stability of
> a patch committed.
It's tricky, because usually the org that wants the thing to work
supplies the thing, and I personally think that provides a meaningful
"demand" signal too. For example, we have external Solaris
representation, but no users of AIX represented at this point, and I
consider that to be quite interesting information. Plenty of people
want PG to work well on their OS or architecture.
But, supposing Azure credits were suddenly available (just between
you, me and the mailing list, I heard that this should be imminent as
some kind of grant to PG US, as a result of the Cirrus thing), do we
have a Windows-savvy volunteer to feed and water an animal? I feel
like this case is inevitable anyway because people in our own
community are probably going to be using Windows ARM laptops sooner or
later...
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-31 05:06 Tom Lane <[email protected]>
parent: Thomas Munro <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Tom Lane @ 2023-08-31 05:06 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
Thomas Munro <[email protected]> writes:
> But, supposing Azure credits were suddenly available (just between
> you, me and the mailing list, I heard that this should be imminent as
> some kind of grant to PG US, as a result of the Cirrus thing), do we
> have a Windows-savvy volunteer to feed and water an animal? I feel
> like this case is inevitable anyway because people in our own
> community are probably going to be using Windows ARM laptops sooner or
> later...
That's a good point. The hardware resources to support a buildfarm
animal are really pretty trivial these days. What is important is
an animal owner who is willing to help chase down problems when they
arise.
Maybe we just need to wait for some community members to acquire
those laptops.
regards, tom lane
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-08-31 05:33 Michael Paquier <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 60+ messages in thread
From: Michael Paquier @ 2023-08-31 05:33 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Thomas Munro <[email protected]>; Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Ian Lawrence Barwick <[email protected]>; Julien Rouhaud <[email protected]>; PostgreSQL Hackers <[email protected]>; [email protected]; Jonathan S. Katz <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Lina Iyer <[email protected]>
On Thu, Aug 31, 2023 at 01:06:53AM -0400, Tom Lane wrote:
> That's a good point. The hardware resources to support a buildfarm
> animal are really pretty trivial these days. What is important is
> an animal owner who is willing to help chase down problems when they
> arise.
Unfortunately I don't see myself running that at home. It is too hot
and humid in Summer so the machine would not last. Something in the
cloud would be OK for me, but AWS has no option for a Windows host
with ARM yet.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-09-13 19:12 Peter Eisentraut <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Peter Eisentraut @ 2023-09-13 19:12 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 31.08.23 06:44, Tom Lane wrote:
> I agree. I'm really uncomfortable with claiming support for
> Windows-on-ARM if we don't have a buildfarm member testing it.
> For other platforms that have a track record of multiple
> hardware support, it might not be a stretch ... but Windows was
> so resolutely Intel-only for so long that "it works on ARM" is
> a proposition that I won't trust without hard evidence. There
> are too many bits of that system that might not have gotten the
> word yet, or at least not gotten sufficient testing.
>
> My vote for this is we don't commit without a buildfarm member.
I think we can have a multi-tiered approach, where we can commit support
but consider it experimental until we have buildfarm coverage.
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-09-14 09:39 Daniel Gustafsson <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Daniel Gustafsson @ 2023-09-14 09:39 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
> On 13 Sep 2023, at 21:12, Peter Eisentraut <[email protected]> wrote:
>
> On 31.08.23 06:44, Tom Lane wrote:
>> I agree. I'm really uncomfortable with claiming support for
>> Windows-on-ARM if we don't have a buildfarm member testing it.
>> For other platforms that have a track record of multiple
>> hardware support, it might not be a stretch ... but Windows was
>> so resolutely Intel-only for so long that "it works on ARM" is
>> a proposition that I won't trust without hard evidence. There
>> are too many bits of that system that might not have gotten the
>> word yet, or at least not gotten sufficient testing.
>> My vote for this is we don't commit without a buildfarm member.
>
> I think we can have a multi-tiered approach, where we can commit support but consider it experimental until we have buildfarm coverage.
If it's experimental it should probably be behind an opt-in flag in
autoconf/meson, or be reverted by the time REL_17_STABLE branches unless
coverage has materialized by then.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-09-19 08:33 Peter Eisentraut <[email protected]>
parent: Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Peter Eisentraut @ 2023-09-19 08:33 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 14.09.23 11:39, Daniel Gustafsson wrote:
>> On 13 Sep 2023, at 21:12, Peter Eisentraut <[email protected]> wrote:
>>
>> On 31.08.23 06:44, Tom Lane wrote:
>>> I agree. I'm really uncomfortable with claiming support for
>>> Windows-on-ARM if we don't have a buildfarm member testing it.
>>> For other platforms that have a track record of multiple
>>> hardware support, it might not be a stretch ... but Windows was
>>> so resolutely Intel-only for so long that "it works on ARM" is
>>> a proposition that I won't trust without hard evidence. There
>>> are too many bits of that system that might not have gotten the
>>> word yet, or at least not gotten sufficient testing.
>>> My vote for this is we don't commit without a buildfarm member.
>>
>> I think we can have a multi-tiered approach, where we can commit support but consider it experimental until we have buildfarm coverage.
>
> If it's experimental it should probably be behind an opt-in flag in
> autoconf/meson, or be reverted by the time REL_17_STABLE branches unless
> coverage has materialized by then.
The author's email is bouncing now, due to job change, so it's unlikely
we will see any progress on this anymore. I am setting it to returned
with feedback.
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-09-19 12:35 Anthony Roberts <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Anthony Roberts @ 2023-09-19 12:35 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
Hi,
This was covered earlier in the thread - I have taken this on in Niyas'
stead.
Was there an explicit request for something there? I was under the
impression that this was all just suggestion/theory at the moment.
Thanks,
Anthony
On 19/09/2023 09:33, Peter Eisentraut wrote:
> On 14.09.23 11:39, Daniel Gustafsson wrote:
>>> On 13 Sep 2023, at 21:12, Peter Eisentraut <[email protected]>
>>> wrote:
>>>
>>> On 31.08.23 06:44, Tom Lane wrote:
>>>> I agree. I'm really uncomfortable with claiming support for
>>>> Windows-on-ARM if we don't have a buildfarm member testing it.
>>>> For other platforms that have a track record of multiple
>>>> hardware support, it might not be a stretch ... but Windows was
>>>> so resolutely Intel-only for so long that "it works on ARM" is
>>>> a proposition that I won't trust without hard evidence. There
>>>> are too many bits of that system that might not have gotten the
>>>> word yet, or at least not gotten sufficient testing.
>>>> My vote for this is we don't commit without a buildfarm member.
>>>
>>> I think we can have a multi-tiered approach, where we can commit
>>> support but consider it experimental until we have buildfarm coverage.
>>
>> If it's experimental it should probably be behind an opt-in flag in
>> autoconf/meson, or be reverted by the time REL_17_STABLE branches unless
>> coverage has materialized by then.
>
> The author's email is bouncing now, due to job change, so it's
> unlikely we will see any progress on this anymore. I am setting it to
> returned with feedback.
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2023-09-19 22:59 Michael Paquier <[email protected]>
parent: Anthony Roberts <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2023-09-19 22:59 UTC (permalink / raw)
To: Anthony Roberts <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
> Was there an explicit request for something there? I was under the
> impression that this was all just suggestion/theory at the moment.
Yes. The addition of a buildfarm member registered into the community
facilities, so as it is possible to provide back to developers dynamic
feedback to the new configuration setup you would like to see
supported in PostgreSQL. This has been mentioned a few times on this
thread, around these places:
https://www.postgresql.org/message-id/20220322103011.i6z2tuj4hle23wgx@jrouhaud
https://www.postgresql.org/message-id/[email protected]
https://www.postgresql.org/message-id/[email protected]
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-23 13:46 Dave Cramer <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-23 13:46 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Tue, 19 Sept 2023 at 23:48, Michael Paquier <[email protected]> wrote:
> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
> > Was there an explicit request for something there? I was under the
> > impression that this was all just suggestion/theory at the moment.
>
> Yes. The addition of a buildfarm member registered into the community
> facilities, so as it is possible to provide back to developers dynamic
> feedback to the new configuration setup you would like to see
> supported in PostgreSQL. This has been mentioned a few times on this
> thread, around these places:
>
> https://www.postgresql.org/message-id/20220322103011.i6z2tuj4hle23wgx@jrouhaud
>
> https://www.postgresql.org/message-id/[email protected]
>
> https://www.postgresql.org/message-id/[email protected]
> --
> Michael
>
The attached patch works with v17. I will work on getting a buildfarm
animal up shortly
Attachments:
[application/octet-stream] windows_arm_build.patch (1.8K, ../../CADK3HH+pKM_xyg2TiWtvtP=P0N-tMtXDKW2AT+7_FLmv4u9Jrg@mail.gmail.com/3-windows_arm_build.patch)
download | inline diff:
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index bb55695300..4a8793a785 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -4120,7 +4120,7 @@ make: *** [postgres] Error 1
<sect3 id="install-windows-full-64-bit">
<title>Special Considerations for 64-Bit Windows</title>
<para>
- PostgreSQL will only build for the x64 architecture on 64-bit Windows.
+ PostgreSQL will only build for the x64 and ARM64 architecture on 64-bit Windows.
</para>
<para>
Mixing 32- and 64-bit versions in the same build tree is not supported.
diff --git a/src/tools/msvc_gendef.pl b/src/tools/msvc_gendef.pl
index 12c49ed265..dfb26916bd 100644
--- a/src/tools/msvc_gendef.pl
+++ b/src/tools/msvc_gendef.pl
@@ -120,9 +120,9 @@ sub writedef
{
my $isdata = $def->{$f} eq 'data';
- # Strip the leading underscore for win32, but not x64
+ # Strip the leading underscore for win32, but not x64 and aarch64
$f =~ s/^_//
- unless ($arch eq "x86_64");
+ unless ($arch eq "x86_64" || $arch eq "aarch64");
# Emit just the name if it's a function symbol, or emit the name
# decorated with the DATA option for variables.
@@ -143,7 +143,7 @@ sub writedef
sub usage
{
die("Usage: msvc_gendef.pl --arch <arch> --deffile <deffile> --tempdir <tempdir> files-or-directories\n"
- . " arch: x86 | x86_64\n"
+ . " arch: x86 | x86_64 | aarch64\n"
. " deffile: path of the generated file\n"
. " tempdir: directory for temporary files\n"
. " files or directories: object files or directory containing object files\n"
@@ -160,7 +160,7 @@ GetOptions(
'tempdir:s' => \$tempdir,) or usage();
usage("arch: $arch")
- unless ($arch eq 'x86' || $arch eq 'x86_64');
+ unless ($arch eq 'x86' || $arch eq 'x86_64' || $arch eq 'aarch64');
my @files;
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-23 21:13 Dave Cramer <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-23 21:13 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Tue, 23 Jan 2024 at 08:46, Dave Cramer <[email protected]> wrote:
>
>
> On Tue, 19 Sept 2023 at 23:48, Michael Paquier <[email protected]>
> wrote:
>
>> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
>> > Was there an explicit request for something there? I was under the
>> > impression that this was all just suggestion/theory at the moment.
>>
>> Yes. The addition of a buildfarm member registered into the community
>> facilities, so as it is possible to provide back to developers dynamic
>> feedback to the new configuration setup you would like to see
>> supported in PostgreSQL. This has been mentioned a few times on this
>> thread, around these places:
>>
>> https://www.postgresql.org/message-id/20220322103011.i6z2tuj4hle23wgx@jrouhaud
>>
>> https://www.postgresql.org/message-id/[email protected]
>>
>> https://www.postgresql.org/message-id/[email protected]
>> --
>> Michael
>>
>
> The attached patch works with v17. I will work on getting a buildfarm
> animal up shortly
>
>
I can build using meson manually, but for some reason building with the
buildfarm fails.
I'm not sure which files to attach to this to help. Andrew, what files do
you need ?
Dave
>
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-23 23:32 Michael Paquier <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2024-01-23 23:32 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote:
> On Tue, 23 Jan 2024 at 08:46, Dave Cramer <[email protected]> wrote:
>> The attached patch works with v17. I will work on getting a buildfarm
>> animal up shortly
Thanks for doing that!
> I can build using meson manually, but for some reason building with the
> buildfarm fails.
>
> I'm not sure which files to attach to this to help. Andrew, what files do
> you need ?
Probably build.ninja and the contents of meson-logs/ would offer
enough information?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-24 11:45 Dave Cramer <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-24 11:45 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Tue, 23 Jan 2024 at 18:32, Michael Paquier <[email protected]> wrote:
> On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote:
> > On Tue, 23 Jan 2024 at 08:46, Dave Cramer <[email protected]>
> wrote:
> >> The attached patch works with v17. I will work on getting a buildfarm
> >> animal up shortly
>
> Thanks for doing that!
>
> > I can build using meson manually, but for some reason building with the
> > buildfarm fails.
> >
> > I'm not sure which files to attach to this to help. Andrew, what files do
> > you need ?
>
> Probably build.ninja and the contents of meson-logs/ would offer
> enough information?
> --
> Michael
>
I managed to get it to build the vcvarsall arch needs to be x64. I need to
add some options, but the patch above needs to be applied to build it.
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 00:02 Michael Paquier <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 2 replies; 60+ messages in thread
From: Michael Paquier @ 2024-01-25 00:02 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to be applied to build it.
Nice. If I may ask, what kind of host and/or configuration have you
used to reach a state where the code can be compiled and run tests
with meson? If you have found specific steps, it may be a good thing
to document that on the wiki, say around [1].
Perhaps you have not included TAP? It may be fine in terms of runtime
checks and coverage.
[1]: https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 13:31 Dave Cramer <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 13:31 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Wed, 24 Jan 2024 at 19:03, Michael Paquier <[email protected]> wrote:
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
> > I managed to get it to build the vcvarsall arch needs to be x64. I need
> to
> > add some options, but the patch above needs to be applied to build it.
>
> Nice. If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson? If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>
I am running a mac-mini M2 with parallels running windows pro 11
The only thing required is this patch. Running in a native developer
prompt
meson setup build --prefix=c:\postgres
cd build
ninja
ninja install
ninja test
all run without errors
I also have buildfarm running and will run that today
Dave
>
> Perhaps you have not included TAP? It may be fine in terms of runtime
> checks and coverage.
>
Does TAP have to be explicitly added to the meson build ?
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 13:45 Dave Cramer <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 13:45 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, 25 Jan 2024 at 08:31, Dave Cramer <[email protected]> wrote:
>
>
> On Wed, 24 Jan 2024 at 19:03, Michael Paquier <[email protected]> wrote:
>
>> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>> > I managed to get it to build the vcvarsall arch needs to be x64. I need
>> to
>> > add some options, but the patch above needs to be applied to build it.
>>
>> Nice. If I may ask, what kind of host and/or configuration have you
>> used to reach a state where the code can be compiled and run tests
>> with meson? If you have found specific steps, it may be a good thing
>> to document that on the wiki, say around [1].
>>
>
> I am running a mac-mini M2 with parallels running windows pro 11
> The only thing required is this patch. Running in a native developer
> prompt
>
> meson setup build --prefix=c:\postgres
> cd build
> ninja
> ninja install
> ninja test
>
> all run without errors
> I also have buildfarm running and will run that today
>
> Dave
>
>>
>> Perhaps you have not included TAP? It may be fine in terms of runtime
>> checks and coverage.
>>
>
> Does TAP have to be explicitly added to the meson build ?
>
> Dave
>
I tried running my buildfarm using my git repo and my branch, but get the
following error
Status Line: 492 bad branch parameter
Content:
bad branch parameter fix_arm
Web txn failed with status: 1
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 17:30 Andrew Dunstan <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 2 replies; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-25 17:30 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-24 We 19:02, Michael Paquier wrote:
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>> I managed to get it to build the vcvarsall arch needs to be x64. I need to
>> add some options, but the patch above needs to be applied to build it.
> Nice. If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson? If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>
> Perhaps you have not included TAP? It may be fine in terms of runtime
> checks and coverage.
>
> [1]:https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we
really want to build with x64_arm64, i.e. to generate native arm64
binaries. Setting just x64 will not do that, AIUI.
I tried that with the buidfarm, setting that in the config file's call
to PGBuild::VSenv::getenv().
That upset msvc_gendef.pl, so I added this there to keep it happy:
$arch = 'x86_64' if $arch eq 'aarch64';
After that things went ok until I got this:
[1453/2088] "link" @src/backend/postgres.exe.rsp
FAILED: src/backend/postgres.exe src/backend/postgres.pdb
"link" @src/backend/postgres.exe.rsp
Creating library src\backend\postgres.exe.lib
storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
_mm_pause referenced in function perform_spin_delay
src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
I haven't made further progress, but I will return to it in the next day
or so.
While this will be nice to have, I think it won't really matter until
there is ARM64 support in released versions of Windows Server. AFAICT
they still only sell versions for x86_64
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 19:07 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 19:07 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-24 We 19:02, Michael Paquier wrote:
>
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to be applied to build it.
>
> Nice. If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson? If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>
> Perhaps you have not included TAP? It may be fine in terms of runtime
> checks and coverage.
>
> [1]: https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
>
>
>
> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we really
> want to build with x64_arm64, i.e. to generate native arm64 binaries.
> Setting just x64 will not do that, AIUI.
>
> I tried that with the buidfarm, setting that in the config file's call to
> PGBuild::VSenv::getenv().
>
> That upset msvc_gendef.pl, so I added this there to keep it happy:
>
> $arch = 'x86_64' if $arch eq 'aarch64';
>
> After that things went ok until I got this:
>
> [1453/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
> Creating library src\backend\postgres.exe.lib
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
> _mm_pause referenced in function perform_spin_delay
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>
>
> I haven't made further progress, but I will return to it in the next day
> or so.
>
> While this will be nice to have, I think it won't really matter until
> there is ARM64 support in released versions of Windows Server. AFAICT they
> still only sell versions for x86_64
>
I need it to build clients. The clients need arm64 libraries to link against
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 19:31 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-25 19:31 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; Michael Paquier <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-25 Th 08:45, Dave Cramer wrote:
>
>
>
>
> I tried running my buildfarm using my git repo and my branch, but get
> the following error
> Status Line: 492 bad branch parameter
> Content:
> bad branch parameter fix_arm
>
> Web txn failed with status: 1
You can't use your own branch with the buildfarm, you need to let it set
up its own branches.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 20:56 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 20:56 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-25 Th 08:45, Dave Cramer wrote:
>
>
>
>
>
> I tried running my buildfarm using my git repo and my branch, but get the
> following error
> Status Line: 492 bad branch parameter
> Content:
> bad branch parameter fix_arm
>
> Web txn failed with status: 1
>
>
>
> You can't use your own branch with the buildfarm, you need to let it set
> up its own branches.
>
So I guess I have to wait until this patch is merged in ?
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 21:01 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 21:01 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-24 We 19:02, Michael Paquier wrote:
>
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to be applied to build it.
>
> Nice. If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson? If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>
> Perhaps you have not included TAP? It may be fine in terms of runtime
> checks and coverage.
>
> [1]: https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
>
>
>
> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we really
> want to build with x64_arm64, i.e. to generate native arm64 binaries.
> Setting just x64 will not do that, AIUI.
>
> I tried that with the buidfarm, setting that in the config file's call to
> PGBuild::VSenv::getenv().
>
> That upset msvc_gendef.pl, so I added this there to keep it happy:
>
> $arch = 'x86_64' if $arch eq 'aarch64';
>
> After that things went ok until I got this:
>
> [1453/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
> Creating library src\backend\postgres.exe.lib
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
> _mm_pause referenced in function perform_spin_delay
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>
>
> I haven't made further progress, but I will return to it in the next day
> or so.
>
> While this will be nice to have, I think it won't really matter until
> there is ARM64 support in released versions of Windows Server. AFAICT they
> still only sell versions for x86_64
>
I've tried it with my patch attached previously and x64_arm64 and it works
fine. builds using the buildfarm as well.
Is there a definitive way to figure out if the binaries are x64_arm64
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 21:03 Anthony Roberts <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Anthony Roberts @ 2024-01-25 21:03 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
Hi David,
Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
Thanks,
Anthony
On Thu, 25 Jan 2024, 21:01 Dave Cramer, <[email protected]> wrote:
>
>
> On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan <[email protected]> wrote:
>
>>
>> On 2024-01-24 We 19:02, Michael Paquier wrote:
>>
>> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>>
>> I managed to get it to build the vcvarsall arch needs to be x64. I need to
>> add some options, but the patch above needs to be applied to build it.
>>
>> Nice. If I may ask, what kind of host and/or configuration have you
>> used to reach a state where the code can be compiled and run tests
>> with meson? If you have found specific steps, it may be a good thing
>> to document that on the wiki, say around [1].
>>
>> Perhaps you have not included TAP? It may be fine in terms of runtime
>> checks and coverage.
>>
>> [1]: https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
>>
>>
>>
>> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we
>> really want to build with x64_arm64, i.e. to generate native arm64
>> binaries. Setting just x64 will not do that, AIUI.
>>
>> I tried that with the buidfarm, setting that in the config file's call to
>> PGBuild::VSenv::getenv().
>>
>> That upset msvc_gendef.pl, so I added this there to keep it happy:
>>
>> $arch = 'x86_64' if $arch eq 'aarch64';
>>
>> After that things went ok until I got this:
>>
>> [1453/2088] "link" @src/backend/postgres.exe.rsp
>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>> "link" @src/backend/postgres.exe.rsp
>> Creating library src\backend\postgres.exe.lib
>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
>> _mm_pause referenced in function perform_spin_delay
>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>
>>
>> I haven't made further progress, but I will return to it in the next day
>> or so.
>>
>> While this will be nice to have, I think it won't really matter until
>> there is ARM64 support in released versions of Windows Server. AFAICT they
>> still only sell versions for x86_64
>>
>
> I've tried it with my patch attached previously and x64_arm64 and it works
> fine. builds using the buildfarm as well.
>
> Is there a definitive way to figure out if the binaries are x64_arm64
>
> Dave
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 21:14 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 0 replies; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-25 21:14 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-25 Th 15:56, Dave Cramer wrote:
>
>
> On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan <[email protected]> wrote:
>
>
> On 2024-01-25 Th 08:45, Dave Cramer wrote:
>>
>>
>>
>>
>> I tried running my buildfarm using my git repo and my branch, but
>> get the following error
>> Status Line: 492 bad branch parameter
>> Content:
>> bad branch parameter fix_arm
>>
>> Web txn failed with status: 1
>
>
>
> You can't use your own branch with the buildfarm, you need to let
> it set up its own branches.
>
>
> So I guess I have to wait until this patch is merged in ?
>
>
Not quite.
There's a switch that lets you test your own code. If you say
--from-source /path/to/repo it will run in whatever state the repo is
in. It won't care what branch you are on, and it won't try to update the
repo. It won't report the results to the server, but it will build and
test everything just like in a regular run. (On the "eat your own dog
food" principle I use this mode a lot.) If you use that mode you
probably also want to specify --verbose as well.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 21:17 Dave Cramer <[email protected]>
parent: Anthony Roberts <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 21:17 UTC (permalink / raw)
To: Anthony Roberts <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, 25 Jan 2024 at 16:04, Anthony Roberts <[email protected]>
wrote:
> Hi David,
>
> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>
> Thanks,
> Anthony
>
So there is another way, select the file in Windows Explorer and right
click, in the compatibility tab if the "Windows on ARM" is greyed out it is
an arm binary.
So far mine are not :(
Thanks,
Dave
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 21:32 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-25 21:32 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; Anthony Roberts <[email protected]>; +Cc: Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-25 Th 16:17, Dave Cramer wrote:
>
>
> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts
> <[email protected]> wrote:
>
> Hi David,
>
> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>
> Thanks,
> Anthony
>
>
>
> So there is another way, select the file in Windows Explorer and right
> click, in the compatibility tab if the "Windows on ARM" is greyed out
> it is an arm binary.
>
> So far mine are not :(
>
Yeah, I think the default Developer Command Prompt for VS2022 is set up
for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-25 21:52 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-25 21:52 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>
>
>
> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts <[email protected]>
> wrote:
>
>> Hi David,
>>
>> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>>
>> Thanks,
>> Anthony
>>
>
>
> So there is another way, select the file in Windows Explorer and right
> click, in the compatibility tab if the "Windows on ARM" is greyed out it is
> an arm binary.
>
> So far mine are not :(
>
>
> Yeah, I think the default Developer Command Prompt for VS2022 is set up
> for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".
>
Yup, now I'm in the same state you are
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-26 01:32 Michael Paquier <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Michael Paquier @ 2024-01-26 01:32 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> wrote:
>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>> Yeah, I think the default Developer Command Prompt for VS2022 is set up
>> for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".
>
> Yup, now I'm in the same state you are
Wait a minute here. Based on [1], x64_arm64 means you can use a x64
host and you'll be able to produce ARM64 builds, still these will not
be able to run on the host where they were built. How much of the
patch posted upthread is required to produce such builds? Basically
everything from it, I guess, so as build dependencies can be
satisfied?
[1]: https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-26 12:36 Andrew Dunstan <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-26 12:36 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Dave Cramer <[email protected]>; +Cc: Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-25 Th 20:32, Michael Paquier wrote:
> On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]> wrote:
>>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>> Yeah, I think the default Developer Command Prompt for VS2022 is set up
>>> for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".
>> Yup, now I'm in the same state you are
> Wait a minute here. Based on [1], x64_arm64 means you can use a x64
> host and you'll be able to produce ARM64 builds, still these will not
> be able to run on the host where they were built. How much of the
> patch posted upthread is required to produce such builds? Basically
> everything from it, I guess, so as build dependencies can be
> satisfied?
>
> [1]: https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
If you look at the table here x86 and x64 are the only supported host
architectures. But that's OK, the x64 binaries will run on arm64 (W11
ARM64 has x64 emulation builtin). If that didn't work Dave and I would
not have got as far as we have. But you want the x64_arm64 argument to
vcvarsall so you will get ARM64 output.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-26 14:18 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 2 replies; 60+ messages in thread
From: Dave Cramer @ 2024-01-26 14:18 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-25 Th 20:32, Michael Paquier wrote:
> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]>
> wrote:
> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
> >>> Yeah, I think the default Developer Command Prompt for VS2022 is set up
> >>> for x86 builds. AIUI you should start by executing "vcvarsall
> x64_arm64".
> >> Yup, now I'm in the same state you are
> > Wait a minute here. Based on [1], x64_arm64 means you can use a x64
> > host and you'll be able to produce ARM64 builds, still these will not
> > be able to run on the host where they were built. How much of the
> > patch posted upthread is required to produce such builds? Basically
> > everything from it, I guess, so as build dependencies can be
> > satisfied?
> >
> > [1]:
> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>
>
> If you look at the table here x86 and x64 are the only supported host
> architectures. But that's OK, the x64 binaries will run on arm64 (W11
> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
> not have got as far as we have. But you want the x64_arm64 argument to
> vcvarsall so you will get ARM64 output.
>
I've rebuilt it using x64_arm64 and with the attached (very naive patch)
and I still get an x64 binary :(
>
>
Attachments:
[application/octet-stream] lock.patch (1.6K, ../../CADK3HHJgTqi7ZeKhBvegTk1=rzDYfGgEJqZN-hNMvQPAJ6R3PA@mail.gmail.com/3-lock.patch)
download | inline diff:
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index aa06e49da2..61f365d0f5 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -256,8 +256,8 @@ spin_delay(void)
* We use the int-width variant of the builtin because it works on more chips
* than other widths.
*/
-#if defined(__arm__) || defined(__arm) || defined(__aarch64__)
-#ifdef HAVE_GCC__SYNC_INT32_TAS
+#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || defined(_M_ARM64)
+//#ifdef HAVE_GCC__SYNC_INT32_TAS
#define HAS_TEST_AND_SET
#define TAS(lock) tas(lock)
@@ -277,7 +277,7 @@ tas(volatile slock_t *lock)
* high-core-count ARM64 processors. It seems mostly a wash for smaller gear,
* and ISB doesn't exist at all on pre-v7 ARM chips.
*/
-#if defined(__aarch64__)
+#if defined(__aarch64__) || defined(_M_ARM64)
#define SPIN_DELAY() spin_delay()
@@ -288,9 +288,9 @@ spin_delay(void)
" isb; \n");
}
-#endif /* __aarch64__ */
-#endif /* HAVE_GCC__SYNC_INT32_TAS */
-#endif /* __arm__ || __arm || __aarch64__ */
+#endif /* __aarch64__ _M_ARM64 */
+//#endif /* HAVE_GCC__SYNC_INT32_TAS */
+#endif /* __arm__ || __arm || __aarch64__ _M_ARM64 */
/* S/390 and S/390x Linux (32- and 64-bit zSeries) */
@@ -710,6 +710,7 @@ typedef LONG slock_t;
/* If using Visual C++ on Win64, inline assembly is unavailable.
* Use a _mm_pause intrinsic instead of rep nop.
*/
+#if !defined(_M_ARM64)
#if defined(_WIN64)
static __forceinline void
spin_delay(void)
@@ -724,6 +725,7 @@ spin_delay(void)
__asm rep nop;
}
#endif
+#endif
#include <intrin.h>
#pragma intrinsic(_ReadWriteBarrier)
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-29 15:35 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
1 sibling, 0 replies; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-29 15:35 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote:
>
>
> On 2024-01-25 Th 20:32, Michael Paquier wrote:
> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
> <[email protected]> wrote:
> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
> >>> Yeah, I think the default Developer Command Prompt for VS2022
> is set up
> >>> for x86 builds. AIUI you should start by executing "vcvarsall
> x64_arm64".
> >> Yup, now I'm in the same state you are
> > Wait a minute here. Based on [1], x64_arm64 means you can use a x64
> > host and you'll be able to produce ARM64 builds, still these
> will not
> > be able to run on the host where they were built. How much of the
> > patch posted upthread is required to produce such builds? Basically
> > everything from it, I guess, so as build dependencies can be
> > satisfied?
> >
> > [1]:
> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>
>
> If you look at the table here x86 and x64 are the only supported host
> architectures. But that's OK, the x64 binaries will run on arm64 (W11
> ARM64 has x64 emulation builtin). If that didn't work Dave and I
> would
> not have got as far as we have. But you want the x64_arm64
> argument to
> vcvarsall so you will get ARM64 output.
>
>
> I've rebuilt it using x64_arm64 and with the attached (very naive
> patch) and I still get an x64 binary :(
I am definitely getting ARM64 binaries (e.g. for initdb.exe the Windows
on ARM compatibility setting is greyed out)
I'll try your patch.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-29 16:16 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
1 sibling, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-29 16:16 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote:
>
>
> On 2024-01-25 Th 20:32, Michael Paquier wrote:
> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
> <[email protected]> wrote:
> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
> >>> Yeah, I think the default Developer Command Prompt for VS2022
> is set up
> >>> for x86 builds. AIUI you should start by executing "vcvarsall
> x64_arm64".
> >> Yup, now I'm in the same state you are
> > Wait a minute here. Based on [1], x64_arm64 means you can use a x64
> > host and you'll be able to produce ARM64 builds, still these
> will not
> > be able to run on the host where they were built. How much of the
> > patch posted upthread is required to produce such builds? Basically
> > everything from it, I guess, so as build dependencies can be
> > satisfied?
> >
> > [1]:
> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>
>
> If you look at the table here x86 and x64 are the only supported host
> architectures. But that's OK, the x64 binaries will run on arm64 (W11
> ARM64 has x64 emulation builtin). If that didn't work Dave and I
> would
> not have got as far as we have. But you want the x64_arm64
> argument to
> vcvarsall so you will get ARM64 output.
>
>
> I've rebuilt it using x64_arm64 and with the attached (very naive
> patch) and I still get an x64 binary :(
With this patch I still get a build error, but it's different :-)
[1406/2088] "link" @src/backend/postgres.exe.rsp
FAILED: src/backend/postgres.exe src/backend/postgres.pdb
"link" @src/backend/postgres.exe.rsp
Creating library src\backend\postgres.exe.lib
storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
spin_delay referenced in function perform_spin_delay
src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-29 16:20 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-29 16:20 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
Dave Cramer
www.postgres.rocks
On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote:
>
>>
>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]>
>> wrote:
>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is set
>> up
>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>> x64_arm64".
>> >> Yup, now I'm in the same state you are
>> > Wait a minute here. Based on [1], x64_arm64 means you can use a x64
>> > host and you'll be able to produce ARM64 builds, still these will not
>> > be able to run on the host where they were built. How much of the
>> > patch posted upthread is required to produce such builds? Basically
>> > everything from it, I guess, so as build dependencies can be
>> > satisfied?
>> >
>> > [1]:
>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>
>>
>> If you look at the table here x86 and x64 are the only supported host
>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>> not have got as far as we have. But you want the x64_arm64 argument to
>> vcvarsall so you will get ARM64 output.
>>
>
> I've rebuilt it using x64_arm64 and with the attached (very naive patch)
> and I still get an x64 binary :(
>
>
> With this patch I still get a build error, but it's different :-)
>
>
> [1406/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
> Creating library src\backend\postgres.exe.lib
>
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
> spin_delay referenced in function perform_spin_delay
>
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>
Did you add the latest lock.patch ?
Dave
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-30 13:38 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-30 13:38 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>
> Dave Cramer
> www.postgres.rocks
>
>
> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote:
>
>
> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>
>>
>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
>> <[email protected]> wrote:
>>
>>
>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
>> <[email protected]> wrote:
>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>> >>> Yeah, I think the default Developer Command Prompt for
>> VS2022 is set up
>> >>> for x86 builds. AIUI you should start by executing
>> "vcvarsall x64_arm64".
>> >> Yup, now I'm in the same state you are
>> > Wait a minute here. Based on [1], x64_arm64 means you can
>> use a x64
>> > host and you'll be able to produce ARM64 builds, still
>> these will not
>> > be able to run on the host where they were built. How much
>> of the
>> > patch posted upthread is required to produce such builds?
>> Basically
>> > everything from it, I guess, so as build dependencies can be
>> > satisfied?
>> >
>> > [1]:
>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>
>>
>> If you look at the table here x86 and x64 are the only
>> supported host
>> architectures. But that's OK, the x64 binaries will run on
>> arm64 (W11
>> ARM64 has x64 emulation builtin). If that didn't work Dave
>> and I would
>> not have got as far as we have. But you want the x64_arm64
>> argument to
>> vcvarsall so you will get ARM64 output.
>>
>>
>> I've rebuilt it using x64_arm64 and with the attached (very
>> naive patch) and I still get an x64 binary :(
>
>
> With this patch I still get a build error, but it's different :-)
>
>
> [1406/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
> Creating library src\backend\postgres.exe.lib
>
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external
> symbol spin_delay referenced in function perform_spin_delay
>
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>
>
> Did you add the latest lock.patch ?
>
>
I'm a bit confused about exactly what needs to be applied. Can you
supply a complete patch to be applied to a pristine checkout that will
let me build?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-30 14:50 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-30 14:50 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>
>
> Dave Cramer
> www.postgres.rocks
>
>
> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote:
>
>>
>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>
>>
>>
>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]> wrote:
>>
>>>
>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]>
>>> wrote:
>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is set
>>> up
>>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>>> x64_arm64".
>>> >> Yup, now I'm in the same state you are
>>> > Wait a minute here. Based on [1], x64_arm64 means you can use a x64
>>> > host and you'll be able to produce ARM64 builds, still these will not
>>> > be able to run on the host where they were built. How much of the
>>> > patch posted upthread is required to produce such builds? Basically
>>> > everything from it, I guess, so as build dependencies can be
>>> > satisfied?
>>> >
>>> > [1]:
>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>
>>>
>>> If you look at the table here x86 and x64 are the only supported host
>>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>>> not have got as far as we have. But you want the x64_arm64 argument to
>>> vcvarsall so you will get ARM64 output.
>>>
>>
>> I've rebuilt it using x64_arm64 and with the attached (very naive patch)
>> and I still get an x64 binary :(
>>
>>
>> With this patch I still get a build error, but it's different :-)
>>
>>
>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>> "link" @src/backend/postgres.exe.rsp
>> Creating library src\backend\postgres.exe.lib
>>
>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
>> spin_delay referenced in function perform_spin_delay
>>
>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>
>
> Did you add the latest lock.patch ?
>
>
>
>
> I'm a bit confused about exactly what needs to be applied. Can you supply
> a complete patch to be applied to a pristine checkout that will let me
> build?
>
>
> cheers
>
See attached.
Dave
Attachments:
[application/octet-stream] 0001-fix-build-for-arm.patch (2.2K, ../../CADK3HHK1e2CEa5fYReZHt-iKcZtEMTZUnNxXoeTCnzyCfcG9Ew@mail.gmail.com/3-0001-fix-build-for-arm.patch)
download | inline diff:
From 19284a00142a1d3854d89b60e641e2048cbf1bb1 Mon Sep 17 00:00:00 2001
From: davecramer <[email protected]>
Date: Tue, 23 Jan 2024 13:29:48 -0500
Subject: [PATCH 1/2] fix build for arm
---
doc/src/sgml/installation.sgml | 2 +-
src/tools/msvc_gendef.pl | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index e73902b3f8..686a342150 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -4150,7 +4150,7 @@ make: *** [postgres] Error 1
<sect3 id="install-windows-full-64-bit">
<title>Special Considerations for 64-Bit Windows</title>
<para>
- PostgreSQL will only build for the x64 architecture on 64-bit Windows.
+ PostgreSQL will only build for the x64 and ARM64 architecture on 64-bit Windows.
</para>
<para>
Mixing 32- and 64-bit versions in the same build tree is not supported.
diff --git a/src/tools/msvc_gendef.pl b/src/tools/msvc_gendef.pl
index 12c49ed265..dfb26916bd 100644
--- a/src/tools/msvc_gendef.pl
+++ b/src/tools/msvc_gendef.pl
@@ -120,9 +120,9 @@ sub writedef
{
my $isdata = $def->{$f} eq 'data';
- # Strip the leading underscore for win32, but not x64
+ # Strip the leading underscore for win32, but not x64 and aarch64
$f =~ s/^_//
- unless ($arch eq "x86_64");
+ unless ($arch eq "x86_64" || $arch eq "aarch64");
# Emit just the name if it's a function symbol, or emit the name
# decorated with the DATA option for variables.
@@ -143,7 +143,7 @@ sub writedef
sub usage
{
die("Usage: msvc_gendef.pl --arch <arch> --deffile <deffile> --tempdir <tempdir> files-or-directories\n"
- . " arch: x86 | x86_64\n"
+ . " arch: x86 | x86_64 | aarch64\n"
. " deffile: path of the generated file\n"
. " tempdir: directory for temporary files\n"
. " files or directories: object files or directory containing object files\n"
@@ -160,7 +160,7 @@ GetOptions(
'tempdir:s' => \$tempdir,) or usage();
usage("arch: $arch")
- unless ($arch eq 'x86' || $arch eq 'x86_64');
+ unless ($arch eq 'x86' || $arch eq 'x86_64' || $arch eq 'aarch64');
my @files;
--
2.43.0.windows.1
[application/octet-stream] 0002-naive-patch-to-fix-locking-for-arm64.patch (1.9K, ../../CADK3HHK1e2CEa5fYReZHt-iKcZtEMTZUnNxXoeTCnzyCfcG9Ew@mail.gmail.com/4-0002-naive-patch-to-fix-locking-for-arm64.patch)
download | inline diff:
From 0661774349f2a96c7aa4aaac328aca4118857f4a Mon Sep 17 00:00:00 2001
From: davecramer <[email protected]>
Date: Tue, 30 Jan 2024 09:47:25 -0500
Subject: [PATCH 2/2] naive patch to fix locking for arm64
---
src/include/storage/s_lock.h | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index aa06e49da2..61f365d0f5 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -256,8 +256,8 @@ spin_delay(void)
* We use the int-width variant of the builtin because it works on more chips
* than other widths.
*/
-#if defined(__arm__) || defined(__arm) || defined(__aarch64__)
-#ifdef HAVE_GCC__SYNC_INT32_TAS
+#if defined(__arm__) || defined(__arm) || defined(__aarch64__) || defined(_M_ARM64)
+//#ifdef HAVE_GCC__SYNC_INT32_TAS
#define HAS_TEST_AND_SET
#define TAS(lock) tas(lock)
@@ -277,7 +277,7 @@ tas(volatile slock_t *lock)
* high-core-count ARM64 processors. It seems mostly a wash for smaller gear,
* and ISB doesn't exist at all on pre-v7 ARM chips.
*/
-#if defined(__aarch64__)
+#if defined(__aarch64__) || defined(_M_ARM64)
#define SPIN_DELAY() spin_delay()
@@ -288,9 +288,9 @@ spin_delay(void)
" isb; \n");
}
-#endif /* __aarch64__ */
-#endif /* HAVE_GCC__SYNC_INT32_TAS */
-#endif /* __arm__ || __arm || __aarch64__ */
+#endif /* __aarch64__ _M_ARM64 */
+//#endif /* HAVE_GCC__SYNC_INT32_TAS */
+#endif /* __arm__ || __arm || __aarch64__ _M_ARM64 */
/* S/390 and S/390x Linux (32- and 64-bit zSeries) */
@@ -710,6 +710,7 @@ typedef LONG slock_t;
/* If using Visual C++ on Win64, inline assembly is unavailable.
* Use a _mm_pause intrinsic instead of rep nop.
*/
+#if !defined(_M_ARM64)
#if defined(_WIN64)
static __forceinline void
spin_delay(void)
@@ -724,6 +725,7 @@ spin_delay(void)
__asm rep nop;
}
#endif
+#endif
#include <intrin.h>
#pragma intrinsic(_ReadWriteBarrier)
--
2.43.0.windows.1
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-30 21:56 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-30 21:56 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Michael Paquier <[email protected]>; Anthony Roberts <[email protected]>; Peter Eisentraut <[email protected]>; Daniel Gustafsson <[email protected]>; Tom Lane <[email protected]>; Mike Holmes <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; PostgreSQL Hackers <[email protected]>; Lina Iyer <[email protected]>
On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>
>
> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email protected]> wrote:
>
>
> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>>
>> Dave Cramer
>> www.postgres.rocks <http://www.postgres.rocks;
>>
>>
>> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan
>> <[email protected]> wrote:
>>
>>
>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>
>>>
>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
>>> <[email protected]> wrote:
>>>
>>>
>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer
>>> wrote:
>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
>>> <[email protected]> wrote:
>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>> >>> Yeah, I think the default Developer Command Prompt
>>> for VS2022 is set up
>>> >>> for x86 builds. AIUI you should start by executing
>>> "vcvarsall x64_arm64".
>>> >> Yup, now I'm in the same state you are
>>> > Wait a minute here. Based on [1], x64_arm64 means you
>>> can use a x64
>>> > host and you'll be able to produce ARM64 builds, still
>>> these will not
>>> > be able to run on the host where they were built. How
>>> much of the
>>> > patch posted upthread is required to produce such
>>> builds? Basically
>>> > everything from it, I guess, so as build dependencies
>>> can be
>>> > satisfied?
>>> >
>>> > [1]:
>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>
>>>
>>> If you look at the table here x86 and x64 are the only
>>> supported host
>>> architectures. But that's OK, the x64 binaries will run
>>> on arm64 (W11
>>> ARM64 has x64 emulation builtin). If that didn't work
>>> Dave and I would
>>> not have got as far as we have. But you want the
>>> x64_arm64 argument to
>>> vcvarsall so you will get ARM64 output.
>>>
>>>
>>> I've rebuilt it using x64_arm64 and with the attached (very
>>> naive patch) and I still get an x64 binary :(
>>
>>
>> With this patch I still get a build error, but it's different :-)
>>
>>
>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>> "link" @src/backend/postgres.exe.rsp
>> Creating library src\backend\postgres.exe.lib
>>
>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved
>> external symbol spin_delay referenced in function
>> perform_spin_delay
>>
>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved
>> externals
>>
>>
>> Did you add the latest lock.patch ?
>>
>>
>
>
> I'm a bit confused about exactly what needs to be applied. Can you
> supply a complete patch to be applied to a pristine checkout that
> will let me build?
>
>
> cheers
>
>
> See attached.
>
>
No, that is what is giving me the error shown above (just tried again to
be certain). And it's not surprising, as patch 2 #ifdef's out the
definition of spin_delay().
If you can get a complete build with these patches then I suspect you're
not doing a proper ARM64 build.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-30 22:54 Dave Cramer <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Dave Cramer @ 2024-01-30 22:54 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; Peter Eisentraut <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]>
On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan <[email protected]> wrote:
>
> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>
>
>
> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <[email protected]> wrote:
>
>>
>> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>>
>>
>> Dave Cramer
>> www.postgres.rocks
>>
>>
>> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <[email protected]> wrote:
>>
>>>
>>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>
>>>
>>>
>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <[email protected]>
>>> wrote:
>>>
>>>>
>>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan <[email protected]>
>>>> wrote:
>>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is
>>>> set up
>>>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>>>> x64_arm64".
>>>> >> Yup, now I'm in the same state you are
>>>> > Wait a minute here. Based on [1], x64_arm64 means you can use a x64
>>>> > host and you'll be able to produce ARM64 builds, still these will not
>>>> > be able to run on the host where they were built. How much of the
>>>> > patch posted upthread is required to produce such builds? Basically
>>>> > everything from it, I guess, so as build dependencies can be
>>>> > satisfied?
>>>> >
>>>> > [1]:
>>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>>
>>>>
>>>> If you look at the table here x86 and x64 are the only supported host
>>>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>>>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>>>> not have got as far as we have. But you want the x64_arm64 argument to
>>>> vcvarsall so you will get ARM64 output.
>>>>
>>>
>>> I've rebuilt it using x64_arm64 and with the attached (very naive
>>> patch) and I still get an x64 binary :(
>>>
>>>
>>> With this patch I still get a build error, but it's different :-)
>>>
>>>
>>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>>> "link" @src/backend/postgres.exe.rsp
>>> Creating library src\backend\postgres.exe.lib
>>>
>>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
>>> spin_delay referenced in function perform_spin_delay
>>>
>>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>>
>>
>> Did you add the latest lock.patch ?
>>
>>
>>
>>
>> I'm a bit confused about exactly what needs to be applied. Can you supply
>> a complete patch to be applied to a pristine checkout that will let me
>> build?
>>
>>
>> cheers
>>
>
> See attached.
>
>
>
> No, that is what is giving me the error shown above (just tried again to
> be certain). And it's not surprising, as patch 2 #ifdef's out the
> definition of spin_delay().
>
> If you can get a complete build with these patches then I suspect you're
> not doing a proper ARM64 build.
>
>
Okay I will look when I get home in a week
Dave
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-31 15:20 Andrew Dunstan <[email protected]>
parent: Dave Cramer <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-31 15:20 UTC (permalink / raw)
To: Dave Cramer <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; Peter Eisentraut <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]>
On 2024-01-30 Tu 17:54, Dave Cramer wrote:
>
>
>
> On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan <[email protected]>
> wrote:
>
>
> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>>
>>
>> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan
>> <[email protected]> wrote:
>>
>>
>> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>>>
>>> Dave Cramer
>>> www.postgres.rocks <http://www.postgres.rocks;
>>>
>>>
>>> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan
>>> <[email protected]> wrote:
>>>
>>>
>>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>>
>>>>
>>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave
>>>> Cramer wrote:
>>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
>>>> <[email protected]> wrote:
>>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>>> >>> Yeah, I think the default Developer Command
>>>> Prompt for VS2022 is set up
>>>> >>> for x86 builds. AIUI you should start by
>>>> executing "vcvarsall x64_arm64".
>>>> >> Yup, now I'm in the same state you are
>>>> > Wait a minute here. Based on [1], x64_arm64 means
>>>> you can use a x64
>>>> > host and you'll be able to produce ARM64 builds,
>>>> still these will not
>>>> > be able to run on the host where they were built.
>>>> How much of the
>>>> > patch posted upthread is required to produce such
>>>> builds? Basically
>>>> > everything from it, I guess, so as build
>>>> dependencies can be
>>>> > satisfied?
>>>> >
>>>> > [1]:
>>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>>
>>>>
>>>> If you look at the table here x86 and x64 are the
>>>> only supported host
>>>> architectures. But that's OK, the x64 binaries will
>>>> run on arm64 (W11
>>>> ARM64 has x64 emulation builtin). If that didn't
>>>> work Dave and I would
>>>> not have got as far as we have. But you want the
>>>> x64_arm64 argument to
>>>> vcvarsall so you will get ARM64 output.
>>>>
>>>>
>>>> I've rebuilt it using x64_arm64 and with the attached
>>>> (very naive patch) and I still get an x64 binary :(
>>>
>>>
>>> With this patch I still get a build error, but it's
>>> different :-)
>>>
>>>
>>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>>> "link" @src/backend/postgres.exe.rsp
>>> Creating library src\backend\postgres.exe.lib
>>>
>>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved
>>> external symbol spin_delay referenced in function
>>> perform_spin_delay
>>>
>>> src\backend\postgres.exe : fatal error LNK1120: 1
>>> unresolved externals
>>>
>>>
>>> Did you add the latest lock.patch ?
>>>
>>>
>>
>>
>> I'm a bit confused about exactly what needs to be applied.
>> Can you supply a complete patch to be applied to a pristine
>> checkout that will let me build?
>>
>>
>> cheers
>>
>>
>> See attached.
>>
>>
>
> No, that is what is giving me the error shown above (just tried
> again to be certain). And it's not surprising, as patch 2 #ifdef's
> out the definition of spin_delay().
>
> If you can get a complete build with these patches then I suspect
> you're not doing a proper ARM64 build.
>
>
> Okay I will look when I get home in a week
I made some progress. The attached is mostly taken from
<https://postgr.es/m/[email protected];
With it applied I was able to get a successful build using the buildfarm
client. However, there are access violations when running some tests, so
there is still some work to do, apparently.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Attachments:
[text/x-patch] arm64.patch (3.9K, ../../[email protected]/3-arm64.patch)
download | inline diff:
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index ed5b285a5e..d9b8649dab 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -4150,7 +4150,7 @@ make: *** [postgres] Error 1
<sect3 id="install-windows-full-64-bit">
<title>Special Considerations for 64-Bit Windows</title>
<para>
- PostgreSQL will only build for the x64 architecture on 64-bit Windows.
+ PostgreSQL will only build for the x64 and ARM64 architecture on 64-bit Windows.
</para>
<para>
Mixing 32- and 64-bit versions in the same build tree is not supported.
diff --git a/meson.build b/meson.build
index 8ed51b6aae..14aea924ec 100644
--- a/meson.build
+++ b/meson.build
@@ -2046,8 +2046,11 @@ int main(void)
elif host_cpu == 'arm' or host_cpu == 'aarch64'
prog = '''
+#ifdef _MSC_VER
+#include <intrin.h>
+#else
#include <arm_acle.h>
-
+#endif
int main(void)
{
unsigned int crc = 0;
@@ -2061,7 +2064,11 @@ int main(void)
}
'''
- if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd without -march=armv8-a+crc',
+ if cc.get_id() == 'msvc'
+ cdata.set('USE_ARMV8_CRC32C', false)
+ cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
+ have_optimized_crc = true
+ elif cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and __crc32cd without -march=armv8-a+crc',
args: test_c_args)
# Use ARM CRC Extension unconditionally
cdata.set('USE_ARMV8_CRC32C', 1)
diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h
index 69582f4ae7..44abd42691 100644
--- a/src/include/storage/s_lock.h
+++ b/src/include/storage/s_lock.h
@@ -707,15 +707,31 @@ typedef LONG slock_t;
#define SPIN_DELAY() spin_delay()
-/* If using Visual C++ on Win64, inline assembly is unavailable.
- * Use a _mm_pause intrinsic instead of rep nop.
+/*
+ * If using Visual C++ on Win64, inline assembly is unavailable.
+ * Use architecture specific intrinsics.
*/
#if defined(_WIN64)
+/*
+ * For Arm64, use __isb intrinsic. See aarch64 inline assembly definition for details.
+ */
+#ifdef _M_ARM64
+static __forceinline void
+spin_delay(void)
+{
+ /* Reference: https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics#BarrierRestrictions */
+ __isb(_ARM64_BARRIER_SY);
+}
+#else
+/*
+ * For x64, use _mm_pause intrinsic instead of rep nop.
+ */
static __forceinline void
spin_delay(void)
{
_mm_pause();
}
+#endif
#else
static __forceinline void
spin_delay(void)
diff --git a/src/port/pg_crc32c_armv8.c b/src/port/pg_crc32c_armv8.c
index d47d838c50..f18903a68a 100644
--- a/src/port/pg_crc32c_armv8.c
+++ b/src/port/pg_crc32c_armv8.c
@@ -14,7 +14,9 @@
*/
#include "c.h"
+#ifndef _MSC_VER
#include <arm_acle.h>
+#endif
#include "port/pg_crc32c.h"
diff --git a/src/tools/msvc_gendef.pl b/src/tools/msvc_gendef.pl
index 12c49ed265..dfb26916bd 100644
--- a/src/tools/msvc_gendef.pl
+++ b/src/tools/msvc_gendef.pl
@@ -120,9 +120,9 @@ sub writedef
{
my $isdata = $def->{$f} eq 'data';
- # Strip the leading underscore for win32, but not x64
+ # Strip the leading underscore for win32, but not x64 and aarch64
$f =~ s/^_//
- unless ($arch eq "x86_64");
+ unless ($arch eq "x86_64" || $arch eq "aarch64");
# Emit just the name if it's a function symbol, or emit the name
# decorated with the DATA option for variables.
@@ -143,7 +143,7 @@ sub writedef
sub usage
{
die("Usage: msvc_gendef.pl --arch <arch> --deffile <deffile> --tempdir <tempdir> files-or-directories\n"
- . " arch: x86 | x86_64\n"
+ . " arch: x86 | x86_64 | aarch64\n"
. " deffile: path of the generated file\n"
. " tempdir: directory for temporary files\n"
. " files or directories: object files or directory containing object files\n"
@@ -160,7 +160,7 @@ GetOptions(
'tempdir:s' => \$tempdir,) or usage();
usage("arch: $arch")
- unless ($arch eq 'x86' || $arch eq 'x86_64');
+ unless ($arch eq 'x86' || $arch eq 'x86_64' || $arch eq 'aarch64');
my @files;
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-31 15:34 Peter Eisentraut <[email protected]>
parent: Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 60+ messages in thread
From: Peter Eisentraut @ 2024-01-31 15:34 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; Dave Cramer <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]>
On 31.01.24 16:20, Andrew Dunstan wrote:
> - PostgreSQL will only build for the x64 architecture on 64-bit Windows.
> + PostgreSQL will only build for the x64 and ARM64 architecture on
> 64-bit Windows.
Are there any other 64-bit architectures for Windows?
Possibly, the original sentence was meant to communicate that ARM was
not supported, in which case it could now be removed?
^ permalink raw reply [nested|flat] 60+ messages in thread
* Re: [PATCH] Add native windows on arm64 support
@ 2024-01-31 15:41 Andrew Dunstan <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 60+ messages in thread
From: Andrew Dunstan @ 2024-01-31 15:41 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Dave Cramer <[email protected]>; +Cc: Andres Freund <[email protected]>; Anthony Roberts <[email protected]>; Daniel Gustafsson <[email protected]>; Lina Iyer <[email protected]>; Michael Paquier <[email protected]>; Mike Holmes <[email protected]>; PostgreSQL Hackers <[email protected]>; Thomas Munro <[email protected]>; Tom Lane <[email protected]>
On 2024-01-31 We 10:34, Peter Eisentraut wrote:
> On 31.01.24 16:20, Andrew Dunstan wrote:
>> - PostgreSQL will only build for the x64 architecture on 64-bit
>> Windows. + PostgreSQL will only build for the x64 and ARM64
>> architecture on 64-bit Windows.
>
> Are there any other 64-bit architectures for Windows?
>
> Possibly, the original sentence was meant to communicate that ARM was
> not supported, in which case it could now be removed?
x86? That is in fact the default setting for VS even on ARM64.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 60+ messages in thread
* [PATCH v5 2/4] pg_upgrade: bump minimum supported version to v10
@ 2026-04-17 18:20 Nathan Bossart <[email protected]>
0 siblings, 0 replies; 60+ messages in thread
From: Nathan Bossart @ 2026-04-17 18:20 UTC (permalink / raw)
---
doc/src/sgml/ref/pgupgrade.sgml | 2 +-
src/bin/pg_upgrade/check.c | 157 +----------------------
src/bin/pg_upgrade/controldata.c | 12 +-
src/bin/pg_upgrade/exec.c | 23 ----
src/bin/pg_upgrade/file.c | 164 -------------------------
src/bin/pg_upgrade/multixact_rewrite.c | 11 +-
src/bin/pg_upgrade/pg_upgrade.c | 31 +----
src/bin/pg_upgrade/pg_upgrade.h | 29 -----
src/bin/pg_upgrade/relfilenumber.c | 37 +-----
src/bin/pg_upgrade/version.c | 127 -------------------
10 files changed, 16 insertions(+), 577 deletions(-)
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index cc44983a9a8..e4e8c02e6d6 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -67,7 +67,7 @@ PostgreSQL documentation
</para>
<para>
- <application>pg_upgrade</application> supports upgrades from 9.2.X and later to the current
+ <application>pg_upgrade</application> supports upgrades from 10.X and later to the current
major release of <productname>PostgreSQL</productname>, including snapshot and beta releases.
</para>
diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c
index f8f31382835..01b354e3c44 100644
--- a/src/bin/pg_upgrade/check.c
+++ b/src/bin/pg_upgrade/check.c
@@ -28,7 +28,6 @@ static void check_for_incompatible_polymorphics(ClusterInfo *cluster);
static void check_for_tables_with_oids(ClusterInfo *cluster);
static void check_for_not_null_inheritance(ClusterInfo *cluster);
static void check_for_gist_inet_ops(ClusterInfo *cluster);
-static void check_for_pg_role_prefix(ClusterInfo *cluster);
static void check_for_new_tablespace_dir(void);
static void check_for_user_defined_encoding_conversions(ClusterInfo *cluster);
static void check_for_unicode_update(ClusterInfo *cluster);
@@ -128,26 +127,6 @@ static DataTypesUsageChecks data_types_usage_checks[] =
.threshold_version = ALL_VERSIONS
},
- /*
- * 9.3 -> 9.4 Fully implement the 'line' data type in 9.4, which
- * previously returned "not enabled" by default and was only functionally
- * enabled with a compile-time switch; as of 9.4 "line" has a different
- * on-disk representation format.
- */
- {
- .status = gettext_noop("Checking for incompatible \"line\" data type"),
- .report_filename = "tables_using_line.txt",
- .base_query =
- "SELECT 'pg_catalog.line'::pg_catalog.regtype AS oid",
- .report_text =
- gettext_noop("Your installation contains the \"line\" data type in user tables.\n"
- "This data type changed its internal and input/output format\n"
- "between your old and new versions so this\n"
- "cluster cannot currently be upgraded. You can\n"
- "drop the problem columns and restart the upgrade.\n"),
- .threshold_version = 903
- },
-
/*
* pg_upgrade only preserves these system values: pg_class.oid pg_type.oid
* pg_enum.oid
@@ -209,30 +188,6 @@ static DataTypesUsageChecks data_types_usage_checks[] =
.threshold_version = 1500
},
- /*
- * It's no longer allowed to create tables or views with "unknown"-type
- * columns. We do not complain about views with such columns, because
- * they should get silently converted to "text" columns during the DDL
- * dump and reload; it seems unlikely to be worth making users do that by
- * hand. However, if there's a table with such a column, the DDL reload
- * will fail, so we should pre-detect that rather than failing
- * mid-upgrade. Worse, if there's a matview with such a column, the DDL
- * reload will silently change it to "text" which won't match the on-disk
- * storage (which is like "cstring"). So we *must* reject that.
- */
- {
- .status = gettext_noop("Checking for invalid \"unknown\" user columns"),
- .report_filename = "tables_using_unknown.txt",
- .base_query =
- "SELECT 'pg_catalog.unknown'::pg_catalog.regtype AS oid",
- .report_text =
- gettext_noop("Your installation contains the \"unknown\" data type in user tables.\n"
- "This data type is no longer allowed in tables, so this cluster\n"
- "cannot currently be upgraded. You can drop the problem columns\n"
- "and restart the upgrade.\n"),
- .threshold_version = 906
- },
-
/*
* PG 12 changed the 'sql_identifier' type storage to be based on name,
* not varchar, which breaks on-disk format for existing data. So we need
@@ -255,23 +210,6 @@ static DataTypesUsageChecks data_types_usage_checks[] =
.threshold_version = 1100
},
- /*
- * JSONB changed its storage format during 9.4 beta, so check for it.
- */
- {
- .status = gettext_noop("Checking for incompatible \"jsonb\" data type in user tables"),
- .report_filename = "tables_using_jsonb.txt",
- .base_query =
- "SELECT 'pg_catalog.jsonb'::pg_catalog.regtype AS oid",
- .report_text =
- gettext_noop("Your installation contains the \"jsonb\" data type in user tables.\n"
- "The internal format of \"jsonb\" changed during 9.4 beta so this\n"
- "cluster cannot currently be upgraded. You can drop the problem \n"
- "columns and restart the upgrade.\n"),
- .threshold_version = MANUAL_CHECK,
- .version_hook = jsonb_9_4_check_applicable
- },
-
/*
* PG 12 removed types abstime, reltime, tinterval.
*/
@@ -712,20 +650,6 @@ check_and_dump_old_cluster(void)
if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1800)
check_for_gist_inet_ops(&old_cluster);
- /*
- * Pre-PG 10 allowed tables with 'unknown' type columns and non WAL logged
- * hash indexes
- */
- if (GET_MAJOR_VERSION(old_cluster.major_version) <= 906)
- {
- if (user_opts.check)
- old_9_6_invalidate_hash_indexes(&old_cluster, true);
- }
-
- /* 9.5 and below should not have roles starting with pg_ */
- if (GET_MAJOR_VERSION(old_cluster.major_version) <= 905)
- check_for_pg_role_prefix(&old_cluster);
-
/*
* While not a check option, we do this now because this is the only time
* the old server is running.
@@ -772,20 +696,6 @@ check_new_cluster(void)
* system boundaries.
*/
check_hard_link(TRANSFER_MODE_SWAP);
-
- /*
- * There are a few known issues with using --swap to upgrade from
- * versions older than 10. For example, the sequence tuple format
- * changed in v10, and the visibility map format changed in 9.6.
- * While such problems are not insurmountable (and we may have to
- * deal with similar problems in the future, anyway), it doesn't
- * seem worth the effort to support swap mode for upgrades from
- * long-unsupported versions.
- */
- if (GET_MAJOR_VERSION(old_cluster.major_version) < 1000)
- pg_fatal("Swap mode can only upgrade clusters from PostgreSQL version %s and later.",
- "10");
-
break;
}
@@ -831,10 +741,6 @@ issue_warnings_and_set_wal_level(void)
*/
start_postmaster(&new_cluster, true);
- /* Reindex hash indexes for old < 10.0 */
- if (GET_MAJOR_VERSION(old_cluster.major_version) <= 906)
- old_9_6_invalidate_hash_indexes(&new_cluster, false);
-
report_extension_updates(&new_cluster);
stop_postmaster(false);
@@ -892,9 +798,9 @@ check_cluster_versions(void)
* upgrades
*/
- if (GET_MAJOR_VERSION(old_cluster.major_version) < 902)
+ if (GET_MAJOR_VERSION(old_cluster.major_version) < 10)
pg_fatal("This utility can only upgrade from PostgreSQL version %s and later.",
- "9.2");
+ "10");
/* Only current PG version is supported as a target */
if (GET_MAJOR_VERSION(new_cluster.major_version) != GET_MAJOR_VERSION(PG_VERSION_NUM))
@@ -1569,12 +1475,10 @@ check_for_incompatible_polymorphics(ClusterInfo *cluster)
", 'array_cat(anyarray,anyarray)'"
", 'array_prepend(anyelement,anyarray)'");
- if (GET_MAJOR_VERSION(cluster->major_version) >= 903)
appendPQExpBufferStr(&old_polymorphics,
", 'array_remove(anyarray,anyelement)'"
", 'array_replace(anyarray,anyelement,anyelement)'");
- if (GET_MAJOR_VERSION(cluster->major_version) >= 905)
appendPQExpBufferStr(&old_polymorphics,
", 'array_position(anyarray,anyelement)'"
", 'array_position(anyarray,anyelement,integer)'"
@@ -1870,63 +1774,6 @@ check_for_gist_inet_ops(ClusterInfo *cluster)
check_ok();
}
-/*
- * check_for_pg_role_prefix()
- *
- * Versions older than 9.6 should not have any pg_* roles
- */
-static void
-check_for_pg_role_prefix(ClusterInfo *cluster)
-{
- PGresult *res;
- PGconn *conn = connectToServer(cluster, "template1");
- int ntups;
- int i_roloid;
- int i_rolname;
- FILE *script = NULL;
- char output_path[MAXPGPATH];
-
- prep_status("Checking for roles starting with \"pg_\"");
-
- snprintf(output_path, sizeof(output_path), "%s/%s",
- log_opts.basedir,
- "pg_role_prefix.txt");
-
- res = executeQueryOrDie(conn,
- "SELECT oid AS roloid, rolname "
- "FROM pg_catalog.pg_roles "
- "WHERE rolname ~ '^pg_'");
-
- ntups = PQntuples(res);
- i_roloid = PQfnumber(res, "roloid");
- i_rolname = PQfnumber(res, "rolname");
- for (int rowno = 0; rowno < ntups; rowno++)
- {
- if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
- pg_fatal("could not open file \"%s\": %m", output_path);
- fprintf(script, "%s (oid=%s)\n",
- PQgetvalue(res, rowno, i_rolname),
- PQgetvalue(res, rowno, i_roloid));
- }
-
- PQclear(res);
-
- PQfinish(conn);
-
- if (script)
- {
- fclose(script);
- pg_log(PG_REPORT, "fatal");
- pg_fatal("Your installation contains roles starting with \"pg_\".\n"
- "\"pg_\" is a reserved prefix for system roles. The cluster\n"
- "cannot be upgraded until these roles are renamed.\n"
- "A list of roles starting with \"pg_\" is in the file:\n"
- " %s", output_path);
- }
- else
- check_ok();
-}
-
/*
* Callback function for processing results of query for
* check_for_user_defined_encoding_conversions()'s UpgradeTask. If the query
diff --git a/src/bin/pg_upgrade/controldata.c b/src/bin/pg_upgrade/controldata.c
index cffcd4b0eba..8188355240f 100644
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -602,14 +602,12 @@ get_control_data(ClusterInfo *cluster)
/* verify that we got all the mandatory pg_control data */
if (!got_xid || !got_oid ||
!got_multi || !got_oldestxid ||
- (!got_oldestmulti &&
- cluster->controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER) ||
+ !got_oldestmulti ||
!got_mxoff || (!live_check && !got_nextxlogfile) ||
!got_float8_pass_by_value || !got_align || !got_blocksz ||
!got_largesz || !got_walsz || !got_walseg || !got_ident ||
!got_index || !got_toast ||
- (!got_large_object &&
- cluster->controldata.ctrl_ver >= LARGE_OBJECT_SIZE_PG_CONTROL_VER) ||
+ !got_large_object ||
!got_date_is_int || !got_data_checksum_version ||
(!got_default_char_signedness &&
cluster->controldata.cat_ver >= DEFAULT_CHAR_SIGNEDNESS_CAT_VER))
@@ -630,8 +628,7 @@ get_control_data(ClusterInfo *cluster)
if (!got_multi)
pg_log(PG_REPORT, " latest checkpoint next MultiXactId");
- if (!got_oldestmulti &&
- cluster->controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER)
+ if (!got_oldestmulti)
pg_log(PG_REPORT, " latest checkpoint oldest MultiXactId");
if (!got_oldestxid)
@@ -670,8 +667,7 @@ get_control_data(ClusterInfo *cluster)
if (!got_toast)
pg_log(PG_REPORT, " maximum TOAST chunk size");
- if (!got_large_object &&
- cluster->controldata.ctrl_ver >= LARGE_OBJECT_SIZE_PG_CONTROL_VER)
+ if (!got_large_object)
pg_log(PG_REPORT, " large-object chunk size");
if (!got_date_is_int)
diff --git a/src/bin/pg_upgrade/exec.c b/src/bin/pg_upgrade/exec.c
index 563b4a6b5fa..44355feea30 100644
--- a/src/bin/pg_upgrade/exec.c
+++ b/src/bin/pg_upgrade/exec.c
@@ -55,16 +55,7 @@ get_bin_version(ClusterInfo *cluster)
if (sscanf(cmd_output, "%*s %*s %d.%d", &v1, &v2) < 1)
pg_fatal("could not get pg_ctl version output from %s", cmd);
- if (v1 < 10)
- {
- /* old style, e.g. 9.6.1 */
- cluster->bin_version = v1 * 10000 + v2 * 100;
- }
- else
- {
- /* new style, e.g. 10.1 */
cluster->bin_version = v1 * 10000;
- }
}
@@ -353,17 +344,7 @@ check_data_dir(ClusterInfo *cluster)
check_single_dir(pg_data, "pg_subtrans");
check_single_dir(pg_data, PG_TBLSPC_DIR);
check_single_dir(pg_data, "pg_twophase");
-
- /* pg_xlog has been renamed to pg_wal in v10 */
- if (GET_MAJOR_VERSION(cluster->major_version) <= 906)
- check_single_dir(pg_data, "pg_xlog");
- else
check_single_dir(pg_data, "pg_wal");
-
- /* pg_clog has been renamed to pg_xact in v10 */
- if (GET_MAJOR_VERSION(cluster->major_version) <= 906)
- check_single_dir(pg_data, "pg_clog");
- else
check_single_dir(pg_data, "pg_xact");
}
@@ -404,10 +385,6 @@ check_bin_dir(ClusterInfo *cluster, bool check_versions)
*/
get_bin_version(cluster);
- /* pg_resetxlog has been renamed to pg_resetwal in version 10 */
- if (GET_MAJOR_VERSION(cluster->bin_version) <= 906)
- check_exec(cluster->bindir, "pg_resetxlog", check_versions);
- else
check_exec(cluster->bindir, "pg_resetwal", check_versions);
if (cluster == &new_cluster)
diff --git a/src/bin/pg_upgrade/file.c b/src/bin/pg_upgrade/file.c
index 5b276008614..af82c0de490 100644
--- a/src/bin/pg_upgrade/file.c
+++ b/src/bin/pg_upgrade/file.c
@@ -20,12 +20,8 @@
#include <linux/fs.h>
#endif
-#include "access/visibilitymapdefs.h"
#include "common/file_perm.h"
#include "pg_upgrade.h"
-#include "storage/bufpage.h"
-#include "storage/checksum.h"
-#include "storage/checksum_impl.h"
/*
@@ -196,166 +192,6 @@ linkFile(const char *src, const char *dst,
}
-/*
- * rewriteVisibilityMap()
- *
- * Transform a visibility map file, copying from src to dst.
- * schemaName/relName are relation's SQL name (used for error messages only).
- *
- * In versions of PostgreSQL prior to catversion 201603011, PostgreSQL's
- * visibility map included one bit per heap page; it now includes two.
- * When upgrading a cluster from before that time to a current PostgreSQL
- * version, we could refuse to copy visibility maps from the old cluster
- * to the new cluster; the next VACUUM would recreate them, but at the
- * price of scanning the entire table. So, instead, we rewrite the old
- * visibility maps in the new format. That way, the all-visible bits
- * remain set for the pages for which they were set previously. The
- * all-frozen bits are never set by this conversion; we leave that to VACUUM.
- */
-void
-rewriteVisibilityMap(const char *fromfile, const char *tofile,
- const char *schemaName, const char *relName)
-{
- int src_fd;
- int dst_fd;
- PGIOAlignedBlock buffer;
- PGIOAlignedBlock new_vmbuf;
- ssize_t totalBytesRead = 0;
- ssize_t src_filesize;
- int rewriteVmBytesPerPage;
- BlockNumber new_blkno = 0;
- struct stat statbuf;
-
- /* Compute number of old-format bytes per new page */
- rewriteVmBytesPerPage = (BLCKSZ - SizeOfPageHeaderData) / 2;
-
- if ((src_fd = open(fromfile, O_RDONLY | PG_BINARY, 0)) < 0)
- pg_fatal("error while copying relation \"%s.%s\": could not open file \"%s\": %m",
- schemaName, relName, fromfile);
-
- if (fstat(src_fd, &statbuf) != 0)
- pg_fatal("error while copying relation \"%s.%s\": could not stat file \"%s\": %m",
- schemaName, relName, fromfile);
-
- if ((dst_fd = open(tofile, O_RDWR | O_CREAT | O_EXCL | PG_BINARY,
- pg_file_create_mode)) < 0)
- pg_fatal("error while copying relation \"%s.%s\": could not create file \"%s\": %m",
- schemaName, relName, tofile);
-
- /* Save old file size */
- src_filesize = statbuf.st_size;
-
- /*
- * Turn each visibility map page into 2 pages one by one. Each new page
- * has the same page header as the old one. If the last section of the
- * last page is empty, we skip it, mostly to avoid turning one-page
- * visibility maps for small relations into two pages needlessly.
- */
- while (totalBytesRead < src_filesize)
- {
- ssize_t bytesRead;
- char *old_cur;
- char *old_break;
- char *old_blkend;
- PageHeaderData pageheader;
- bool old_lastblk;
-
- if ((bytesRead = read(src_fd, buffer.data, BLCKSZ)) != BLCKSZ)
- {
- if (bytesRead < 0)
- pg_fatal("error while copying relation \"%s.%s\": could not read file \"%s\": %m",
- schemaName, relName, fromfile);
- else
- pg_fatal("error while copying relation \"%s.%s\": partial page found in file \"%s\"",
- schemaName, relName, fromfile);
- }
-
- totalBytesRead += BLCKSZ;
- old_lastblk = (totalBytesRead == src_filesize);
-
- /* Save the page header data */
- memcpy(&pageheader, buffer.data, SizeOfPageHeaderData);
-
- /*
- * These old_* variables point to old visibility map page. old_cur
- * points to current position on old page. old_blkend points to end of
- * old block. old_break is the end+1 position on the old page for the
- * data that will be transferred to the current new page.
- */
- old_cur = buffer.data + SizeOfPageHeaderData;
- old_blkend = buffer.data + bytesRead;
- old_break = old_cur + rewriteVmBytesPerPage;
-
- while (old_break <= old_blkend)
- {
- char *new_cur;
- bool empty = true;
- bool old_lastpart;
-
- /* First, copy old page header to new page */
- memcpy(new_vmbuf.data, &pageheader, SizeOfPageHeaderData);
-
- /* Rewriting the last part of the last old page? */
- old_lastpart = old_lastblk && (old_break == old_blkend);
-
- new_cur = new_vmbuf.data + SizeOfPageHeaderData;
-
- /* Process old page bytes one by one, and turn it into new page. */
- while (old_cur < old_break)
- {
- uint8 byte = *(uint8 *) old_cur;
- uint16 new_vmbits = 0;
- int i;
-
- /* Generate new format bits while keeping old information */
- for (i = 0; i < BITS_PER_BYTE; i++)
- {
- if (byte & (1 << i))
- {
- empty = false;
- new_vmbits |=
- VISIBILITYMAP_ALL_VISIBLE << (BITS_PER_HEAPBLOCK * i);
- }
- }
-
- /* Copy new visibility map bytes to new-format page */
- new_cur[0] = (char) (new_vmbits & 0xFF);
- new_cur[1] = (char) (new_vmbits >> 8);
-
- old_cur++;
- new_cur += BITS_PER_HEAPBLOCK;
- }
-
- /* If the last part of the last page is empty, skip writing it */
- if (old_lastpart && empty)
- break;
-
- /* Set new checksum for visibility map page, if enabled */
- if (new_cluster.controldata.data_checksum_version != PG_DATA_CHECKSUM_OFF)
- ((PageHeader) new_vmbuf.data)->pd_checksum =
- pg_checksum_page(new_vmbuf.data, new_blkno);
-
- errno = 0;
- if (write(dst_fd, new_vmbuf.data, BLCKSZ) != BLCKSZ)
- {
- /* if write didn't set errno, assume problem is no disk space */
- if (errno == 0)
- errno = ENOSPC;
- pg_fatal("error while copying relation \"%s.%s\": could not write file \"%s\": %m",
- schemaName, relName, tofile);
- }
-
- /* Advance for next new page */
- old_break += rewriteVmBytesPerPage;
- new_blkno++;
- }
- }
-
- /* Clean up */
- close(dst_fd);
- close(src_fd);
-}
-
void
check_file_clone(void)
{
diff --git a/src/bin/pg_upgrade/multixact_rewrite.c b/src/bin/pg_upgrade/multixact_rewrite.c
index 823984ec8f3..c45b3183684 100644
--- a/src/bin/pg_upgrade/multixact_rewrite.c
+++ b/src/bin/pg_upgrade/multixact_rewrite.c
@@ -25,10 +25,7 @@ static void RecordMultiXactMembers(SlruSegState *members_writer,
* 32-bit offsets to the current format.
*
* Multixids in the range [from_multi, to_multi) are read from the old
- * cluster, and written in the new format. An important edge case is that if
- * from_multi == to_multi, this initializes the new pg_multixact files in the
- * new format without trying to open any old files. (We rely on that when
- * upgrading from PostgreSQL version 9.2 or below.)
+ * cluster, and written in the new format.
*
* Returns the new nextOffset value; the caller should set it in the new
* control file. The new members always start from offset 1, regardless of
@@ -42,6 +39,7 @@ rewrite_multixacts(MultiXactId from_multi, MultiXactId to_multi)
SlruSegState *members_writer;
char dir[MAXPGPATH] = {0};
bool prev_multixid_valid = false;
+ OldMultiXactReader *old_reader;
/*
* The range of valid multi XIDs is unchanged by the conversion (they are
@@ -63,10 +61,6 @@ rewrite_multixacts(MultiXactId from_multi, MultiXactId to_multi)
* Convert old multixids, if needed, by reading them one-by-one from the
* old cluster.
*/
- if (to_multi != from_multi)
- {
- OldMultiXactReader *old_reader;
-
old_reader = AllocOldMultiXactRead(old_cluster.pgdata,
old_cluster.controldata.chkpnt_nxtmulti,
old_cluster.controldata.chkpnt_nxtmxoff);
@@ -113,7 +107,6 @@ rewrite_multixacts(MultiXactId from_multi, MultiXactId to_multi)
}
FreeOldMultiXactReader(old_reader);
- }
/* Write the final 'next' offset to the last SLRU page */
RecordMultiXactOffset(offsets_writer, to_multi,
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index 2127d297bfe..e5d7920c1b1 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -714,13 +714,6 @@ create_new_objects(void)
end_progress_output();
check_ok();
- /*
- * We don't have minmxids for databases or relations in pre-9.3 clusters,
- * so set those after we have restored the schema.
- */
- if (GET_MAJOR_VERSION(old_cluster.major_version) <= 902)
- set_frozenxids(true);
-
/* update new_cluster info now that we have objects in the databases */
get_db_rel_and_slot_infos(&new_cluster);
}
@@ -777,10 +770,7 @@ copy_xact_xlog_xid(void)
* Copy old commit logs to new data dir. pg_clog has been renamed to
* pg_xact in post-10 clusters.
*/
- copy_subdir_files(GET_MAJOR_VERSION(old_cluster.major_version) <= 906 ?
- "pg_clog" : "pg_xact",
- GET_MAJOR_VERSION(new_cluster.major_version) <= 906 ?
- "pg_clog" : "pg_xact");
+ copy_subdir_files("pg_xact", "pg_xact");
prep_status("Setting oldest XID for new cluster");
exec_prog(UTILITY_LOG_FILE, NULL, true, true,
@@ -809,7 +799,6 @@ copy_xact_xlog_xid(void)
check_ok();
/* Copy or convert pg_multixact files */
- Assert(new_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER);
Assert(new_cluster.controldata.cat_ver >= MULTIXACTOFFSET_FORMATCHANGE_CAT_VER);
if (old_cluster.controldata.cat_ver >= MULTIXACTOFFSET_FORMATCHANGE_CAT_VER)
{
@@ -844,25 +833,7 @@ copy_xact_xlog_xid(void)
* Determine the range of multixacts to convert.
*/
nxtmulti = old_cluster.controldata.chkpnt_nxtmulti;
- if (old_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER)
- {
- /* Versions 9.3 - 18: convert all multixids */
oldstMulti = old_cluster.controldata.chkpnt_oldstMulti;
- }
- else
- {
- /*
- * In PostgreSQL 9.2 and below, multitransactions were only used
- * for row locking, and as such don't need to be preserved during
- * upgrade. In that case, we utilize rewrite_multixacts() just to
- * initialize new, empty files in the new format.
- *
- * It's important that the oldest multi is set to the latest value
- * used by the old system, so that multixact.c returns the empty
- * set for multis that might be present on disk.
- */
- oldstMulti = nxtmulti;
- }
/* handle wraparound */
if (nxtmulti < FirstMultiXactId)
nxtmulti = FirstMultiXactId;
diff --git a/src/bin/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h
index ccd1ac0d013..d6e5bca5792 100644
--- a/src/bin/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -101,19 +101,6 @@ extern char *output_files[];
#endif
-/*
- * The format of visibility map was changed with this 9.6 commit.
- */
-#define VISIBILITY_MAP_FROZEN_BIT_CAT_VER 201603011
-
-/*
- * pg_multixact format changed in 9.3 commit 0ac5ad5134f2769ccbaefec73844f85,
- * ("Improve concurrency of foreign key locking") which also updated catalog
- * version to this value. pg_upgrade behavior depends on whether old and new
- * server versions are both newer than this, or only the new one is.
- */
-#define MULTIXACT_FORMATCHANGE_CAT_VER 201301231
-
/*
* MultiXactOffset was changed from 32-bit to 64-bit in version 19, at this
* catalog version. pg_multixact files need to be converted when upgrading
@@ -121,17 +108,6 @@ extern char *output_files[];
*/
#define MULTIXACTOFFSET_FORMATCHANGE_CAT_VER 202512091
-/*
- * large object chunk size added to pg_controldata,
- * commit 5f93c37805e7485488480916b4585e098d3cc883
- */
-#define LARGE_OBJECT_SIZE_PG_CONTROL_VER 942
-
-/*
- * change in JSONB format during 9.4 beta
- */
-#define JSONB_FORMAT_CHANGE_CAT_VER 201409291
-
/*
* The control file was changed to have the default char signedness,
* commit 44fe30fdab6746a287163e7cc093fd36cda8eb92
@@ -429,8 +405,6 @@ void copyFileByRange(const char *src, const char *dst,
const char *schemaName, const char *relName);
void linkFile(const char *src, const char *dst,
const char *schemaName, const char *relName);
-void rewriteVisibilityMap(const char *fromfile, const char *tofile,
- const char *schemaName, const char *relName);
void check_file_clone(void);
void check_copy_file_range(void);
void check_hard_link(transferMode transfer_mode);
@@ -500,10 +474,7 @@ unsigned int str2uint(const char *str);
/* version.c */
-bool jsonb_9_4_check_applicable(ClusterInfo *cluster);
bool protocol_negotiation_supported(const ClusterInfo *cluster);
-void old_9_6_invalidate_hash_indexes(ClusterInfo *cluster,
- bool check_mode);
void report_extension_updates(ClusterInfo *cluster);
diff --git a/src/bin/pg_upgrade/relfilenumber.c b/src/bin/pg_upgrade/relfilenumber.c
index d5088447e0d..ec2ff7acb21 100644
--- a/src/bin/pg_upgrade/relfilenumber.c
+++ b/src/bin/pg_upgrade/relfilenumber.c
@@ -18,7 +18,7 @@
#include "pg_upgrade.h"
static void transfer_single_new_db(FileNameMap *maps, int size, char *old_tablespace, char *new_tablespace);
-static void transfer_relfile(FileNameMap *map, const char *type_suffix, bool vm_must_add_frozenbit);
+static void transfer_relfile(FileNameMap *map, const char *type_suffix);
/*
* The following set of sync_queue_* functions are used for --swap to reduce
@@ -496,25 +496,10 @@ transfer_single_new_db(FileNameMap *maps, int size,
char *old_tablespace, char *new_tablespace)
{
int mapnum;
- bool vm_must_add_frozenbit = false;
-
- /*
- * Do we need to rewrite visibilitymap?
- */
- if (old_cluster.controldata.cat_ver < VISIBILITY_MAP_FROZEN_BIT_CAT_VER &&
- new_cluster.controldata.cat_ver >= VISIBILITY_MAP_FROZEN_BIT_CAT_VER)
- vm_must_add_frozenbit = true;
/* --swap has its own subroutine */
if (user_opts.transfer_mode == TRANSFER_MODE_SWAP)
{
- /*
- * We don't support --swap to upgrade from versions that require
- * rewriting the visibility map. We should've failed already if
- * someone tries to do that.
- */
- Assert(!vm_must_add_frozenbit);
-
do_swap(maps, size, old_tablespace, new_tablespace);
return;
}
@@ -525,13 +510,13 @@ transfer_single_new_db(FileNameMap *maps, int size,
strcmp(maps[mapnum].old_tablespace, old_tablespace) == 0)
{
/* transfer primary file */
- transfer_relfile(&maps[mapnum], "", vm_must_add_frozenbit);
+ transfer_relfile(&maps[mapnum], "");
/*
* Copy/link any fsm and vm files, if they exist
*/
- transfer_relfile(&maps[mapnum], "_fsm", vm_must_add_frozenbit);
- transfer_relfile(&maps[mapnum], "_vm", vm_must_add_frozenbit);
+ transfer_relfile(&maps[mapnum], "_fsm");
+ transfer_relfile(&maps[mapnum], "_vm");
}
}
}
@@ -540,12 +525,10 @@ transfer_single_new_db(FileNameMap *maps, int size,
/*
* transfer_relfile()
*
- * Copy or link file from old cluster to new one. If vm_must_add_frozenbit
- * is true, visibility map forks are converted and rewritten, even in link
- * mode.
+ * Copy or link file from old cluster to new one.
*/
static void
-transfer_relfile(FileNameMap *map, const char *type_suffix, bool vm_must_add_frozenbit)
+transfer_relfile(FileNameMap *map, const char *type_suffix)
{
char old_file[MAXPGPATH];
char new_file[MAXPGPATH];
@@ -604,14 +587,6 @@ transfer_relfile(FileNameMap *map, const char *type_suffix, bool vm_must_add_fro
/* Copying files might take some time, so give feedback. */
pg_log(PG_STATUS, "%s", old_file);
- if (vm_must_add_frozenbit && strcmp(type_suffix, "_vm") == 0)
- {
- /* Need to rewrite visibility map format */
- pg_log(PG_VERBOSE, "rewriting \"%s\" to \"%s\"",
- old_file, new_file);
- rewriteVisibilityMap(old_file, new_file, map->nspname, map->relname);
- }
- else
switch (user_opts.transfer_mode)
{
case TRANSFER_MODE_CLONE:
diff --git a/src/bin/pg_upgrade/version.c b/src/bin/pg_upgrade/version.c
index 047670d4acb..9e83d4659be 100644
--- a/src/bin/pg_upgrade/version.c
+++ b/src/bin/pg_upgrade/version.c
@@ -12,22 +12,6 @@
#include "fe_utils/string_utils.h"
#include "pg_upgrade.h"
-/*
- * version_hook functions for check_for_data_types_usage in order to determine
- * whether a data type check should be executed for the cluster in question or
- * not.
- */
-bool
-jsonb_9_4_check_applicable(ClusterInfo *cluster)
-{
- /* JSONB changed its storage format during 9.4 beta */
- if (GET_MAJOR_VERSION(cluster->major_version) == 904 &&
- cluster->controldata.cat_ver < JSONB_FORMAT_CHANGE_CAT_VER)
- return true;
-
- return false;
-}
-
/*
* Older servers can't support newer protocol versions, so their connection
* strings will need to lock max_protocol_version to 3.0.
@@ -46,117 +30,6 @@ protocol_negotiation_supported(const ClusterInfo *cluster)
return (GET_MAJOR_VERSION(cluster->major_version) >= 1100);
}
-/*
- * old_9_6_invalidate_hash_indexes()
- * 9.6 -> 10
- * Hash index binary format has changed from 9.6->10.0
- */
-void
-old_9_6_invalidate_hash_indexes(ClusterInfo *cluster, bool check_mode)
-{
- int dbnum;
- FILE *script = NULL;
- bool found = false;
- char *output_path = "reindex_hash.sql";
-
- prep_status("Checking for hash indexes");
-
- for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++)
- {
- PGresult *res;
- bool db_used = false;
- int ntups;
- int rowno;
- int i_nspname,
- i_relname;
- DbInfo *active_db = &cluster->dbarr.dbs[dbnum];
- PGconn *conn = connectToServer(cluster, active_db->db_name);
-
- /* find hash indexes */
- res = executeQueryOrDie(conn,
- "SELECT n.nspname, c.relname "
- "FROM pg_catalog.pg_class c, "
- " pg_catalog.pg_index i, "
- " pg_catalog.pg_am a, "
- " pg_catalog.pg_namespace n "
- "WHERE i.indexrelid = c.oid AND "
- " c.relam = a.oid AND "
- " c.relnamespace = n.oid AND "
- " a.amname = 'hash'"
- );
-
- ntups = PQntuples(res);
- i_nspname = PQfnumber(res, "nspname");
- i_relname = PQfnumber(res, "relname");
- for (rowno = 0; rowno < ntups; rowno++)
- {
- found = true;
- if (!check_mode)
- {
- if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL)
- pg_fatal("could not open file \"%s\": %m", output_path);
- if (!db_used)
- {
- PQExpBufferData connectbuf;
-
- initPQExpBuffer(&connectbuf);
- appendPsqlMetaConnect(&connectbuf, active_db->db_name);
- fputs(connectbuf.data, script);
- termPQExpBuffer(&connectbuf);
- db_used = true;
- }
- fprintf(script, "REINDEX INDEX %s.%s;\n",
- quote_identifier(PQgetvalue(res, rowno, i_nspname)),
- quote_identifier(PQgetvalue(res, rowno, i_relname)));
- }
- }
-
- PQclear(res);
-
- if (!check_mode && db_used)
- {
- /* mark hash indexes as invalid */
- PQclear(executeQueryOrDie(conn,
- "UPDATE pg_catalog.pg_index i "
- "SET indisvalid = false "
- "FROM pg_catalog.pg_class c, "
- " pg_catalog.pg_am a, "
- " pg_catalog.pg_namespace n "
- "WHERE i.indexrelid = c.oid AND "
- " c.relam = a.oid AND "
- " c.relnamespace = n.oid AND "
- " a.amname = 'hash'"));
- }
-
- PQfinish(conn);
- }
-
- if (script)
- fclose(script);
-
- if (found)
- {
- report_status(PG_WARNING, "warning");
- if (check_mode)
- pg_log(PG_WARNING, "\n"
- "Your installation contains hash indexes. These indexes have different\n"
- "internal formats between your old and new clusters, so they must be\n"
- "reindexed with the REINDEX command. After upgrading, you will be given\n"
- "REINDEX instructions.");
- else
- pg_log(PG_WARNING, "\n"
- "Your installation contains hash indexes. These indexes have different\n"
- "internal formats between your old and new clusters, so they must be\n"
- "reindexed with the REINDEX command. The file\n"
- " %s\n"
- "when executed by psql by the database superuser will recreate all invalid\n"
- "indexes; until then, none of these indexes will be used.",
- output_path);
- }
- else
- check_ok();
-}
-
/*
* Callback function for processing results of query for
* report_extension_updates()'s UpgradeTask. If the query returned any rows,
--
2.50.1 (Apple Git-155)
--ZcI1PtyEAe3VcVeQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v5-0003-psql-bump-minimum-supported-version-to-v10.patch
^ permalink raw reply [nested|flat] 60+ messages in thread
end of thread, other threads:[~2026-04-17 18:20 UTC | newest]
Thread overview: 60+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-05-06 03:09 Re: [PATCH] Add native windows on arm64 support Michael Paquier <[email protected]>
2023-05-06 04:35 ` Tom Lane <[email protected]>
2023-05-07 00:37 ` Michael Paquier <[email protected]>
2023-05-08 19:17 ` Andres Freund <[email protected]>
2023-05-08 19:58 ` Tom Lane <[email protected]>
2023-05-10 13:24 ` Andrew Dunstan <[email protected]>
2023-05-10 23:34 ` Michael Paquier <[email protected]>
2023-05-11 00:17 ` Thomas Munro <[email protected]>
2023-05-11 04:19 ` Michael Paquier <[email protected]>
2023-07-04 07:34 ` Michael Paquier <[email protected]>
2023-05-11 07:57 ` Niyas Sait <[email protected]>
2023-06-14 12:25 ` Niyas Sait <[email protected]>
2023-08-17 08:41 ` Anthony Roberts <[email protected]>
2023-08-17 22:28 ` Michael Paquier <[email protected]>
2023-08-25 09:40 ` Anthony Roberts <[email protected]>
2023-08-25 10:17 ` Michael Paquier <[email protected]>
2023-08-25 10:34 ` Anthony Roberts <[email protected]>
2023-08-30 15:12 ` Anthony Roberts <[email protected]>
2023-08-31 04:22 ` Michael Paquier <[email protected]>
2023-08-31 04:44 ` Tom Lane <[email protected]>
2023-09-13 19:12 ` Peter Eisentraut <[email protected]>
2023-09-14 09:39 ` Daniel Gustafsson <[email protected]>
2023-09-19 08:33 ` Peter Eisentraut <[email protected]>
2023-09-19 12:35 ` Anthony Roberts <[email protected]>
2023-09-19 22:59 ` Michael Paquier <[email protected]>
2024-01-23 13:46 ` Dave Cramer <[email protected]>
2024-01-23 21:13 ` Dave Cramer <[email protected]>
2024-01-23 23:32 ` Michael Paquier <[email protected]>
2024-01-24 11:45 ` Dave Cramer <[email protected]>
2024-01-25 00:02 ` Michael Paquier <[email protected]>
2024-01-25 13:31 ` Dave Cramer <[email protected]>
2024-01-25 13:45 ` Dave Cramer <[email protected]>
2024-01-25 19:31 ` Andrew Dunstan <[email protected]>
2024-01-25 20:56 ` Dave Cramer <[email protected]>
2024-01-25 21:14 ` Andrew Dunstan <[email protected]>
2024-01-25 17:30 ` Andrew Dunstan <[email protected]>
2024-01-25 19:07 ` Dave Cramer <[email protected]>
2024-01-25 21:01 ` Dave Cramer <[email protected]>
2024-01-25 21:03 ` Anthony Roberts <[email protected]>
2024-01-25 21:17 ` Dave Cramer <[email protected]>
2024-01-25 21:32 ` Andrew Dunstan <[email protected]>
2024-01-25 21:52 ` Dave Cramer <[email protected]>
2024-01-26 01:32 ` Michael Paquier <[email protected]>
2024-01-26 12:36 ` Andrew Dunstan <[email protected]>
2024-01-26 14:18 ` Dave Cramer <[email protected]>
2024-01-29 15:35 ` Andrew Dunstan <[email protected]>
2024-01-29 16:16 ` Andrew Dunstan <[email protected]>
2024-01-29 16:20 ` Dave Cramer <[email protected]>
2024-01-30 13:38 ` Andrew Dunstan <[email protected]>
2024-01-30 14:50 ` Dave Cramer <[email protected]>
2024-01-30 21:56 ` Andrew Dunstan <[email protected]>
2024-01-30 22:54 ` Dave Cramer <[email protected]>
2024-01-31 15:20 ` Andrew Dunstan <[email protected]>
2024-01-31 15:34 ` Peter Eisentraut <[email protected]>
2024-01-31 15:41 ` Andrew Dunstan <[email protected]>
2023-08-31 04:57 ` Thomas Munro <[email protected]>
2023-08-31 05:06 ` Tom Lane <[email protected]>
2023-08-31 05:33 ` Michael Paquier <[email protected]>
2023-08-25 11:48 ` Daniel Gustafsson <[email protected]>
2026-04-17 18:20 [PATCH v5 2/4] pg_upgrade: bump minimum supported version to v10 Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox