Thread: Update Windows CI Task Names: Server 2022 + VS 2022 Upgrade
Hi, Thomas Munro off-list mentioned that the Windows CI image is actually running on Server 2022, even though the task name still refers to Server 2019. He also suggested upgrading the compiler from Visual Studio 2019 to Visual Studio 2022. A PR [1] to upgrade the compiler to VS 2022 is ready in Andres' pg-vm-images repository (where the CI images are built). This VS 2022 image passes all tests for both MinGW [2] and Meson & Ninja [2]. Once it's merged, the CI images will automatically start using the VS 2022 compiler. Two patches are attached, the first one is for fixing server names and the second one is for upgrading the VS compiler version in the task name. Please note: the PR and second patch should be committed simultaneously to avoid mismatches (e.g., a VS 2019 task running with a VS 2022 compiler, or vice versa). Any feedback would be appreciated. [1] https://github.com/anarazel/pg-vm-images/pull/114 [2] https://cirrus-ci.com/build/5095727501672448 -- Regards, Nazir Bilal Yavuz Microsoft
Attachment
On 05.06.25 10:04, Nazir Bilal Yavuz wrote: > Thomas Munro off-list mentioned that the Windows CI image is actually > running on Server 2022, even though the task name still refers to > Server 2019. He also suggested upgrading the compiler from Visual > Studio 2019 to Visual Studio 2022. Some of the tasks for the other operating systems name the version, some don't. We have recently removed the version from the FreeBSD task. Should we remove the versions from the task name everywhere, to avoid having further mismatches? > A PR [1] to upgrade the compiler to VS 2022 is ready in Andres' > pg-vm-images repository (where the CI images are built). This VS 2022 > image passes all tests for both MinGW [2] and Meson & Ninja [2]. Once > it's merged, the CI images will automatically start using the VS 2022 > compiler. Hmm, for the purposes of [0], I think it might be better to keep the image at VS 2019 for now. Unless there are specific reasons why VS 2022 would be of use now? [0]: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a%40eisentraut.org
Hi, On Thu, 5 Jun 2025 at 11:27, Peter Eisentraut <peter@eisentraut.org> wrote: > > On 05.06.25 10:04, Nazir Bilal Yavuz wrote: > > Thomas Munro off-list mentioned that the Windows CI image is actually > > running on Server 2022, even though the task name still refers to > > Server 2019. He also suggested upgrading the compiler from Visual > > Studio 2019 to Visual Studio 2022. > > Some of the tasks for the other operating systems name the version, some > don't. We have recently removed the version from the FreeBSD task. > Should we remove the versions from the task name everywhere, to avoid > having further mismatches? I think one of the biggest advantages of having a version in the task name is immediately seeing if something is updated (without checking -hackers or sysinfo). However, most of the information is already available in the sysinfo in the task and since we removed the version from FreeBSD; I think we can remove it from all of the tasks. > > A PR [1] to upgrade the compiler to VS 2022 is ready in Andres' > > pg-vm-images repository (where the CI images are built). This VS 2022 > > image passes all tests for both MinGW [2] and Meson & Ninja [2]. Once > > it's merged, the CI images will automatically start using the VS 2022 > > compiler. > > Hmm, for the purposes of [0], I think it might be better to keep the > image at VS 2019 for now. Unless there are specific reasons why VS 2022 > would be of use now? Thomas was thinking of trying some new APIs which are available in the VS 2022, he may answer this better. -- Regards, Nazir Bilal Yavuz Microsoft
On Thu, Jun 5, 2025 at 8:48 PM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: > > Hmm, for the purposes of [0], I think it might be better to keep the > > image at VS 2019 for now. Unless there are specific reasons why VS 2022 > > would be of use now? > > Thomas was thinking of trying some new APIs which are available in the > VS 2022, he may answer this better. My goal in asking about that was to have the infrastructure to advance the Windows-on-aarch64 project (as a non-Windows developer trying to advance things based on standards instead of hand-rolling), since that's apparently where their <stdatomic.h> support was added, and I speculate that that is the best way forward for porting our atomics to new platforms: https://www.postgresql.org/message-id/flat/CADK3HHL9hJnCxttPnhPvdNdXC_7ger%3DiarMMy0KOrOOweaMAxw%40mail.gmail.com#75363fb1078b930736ad7fc7b9f95910 I think on your C11 thread I might have been confused about that, since there was an implication that 2019 might support <stdatomic.h>, but it looks like 2019 added language stuff while 2022 added the library stuff. But yeah, given your proposal that MSVC 2019 should be our new minimum target on that platform, I wonder if we should have both available in CI somehow... (Trying to constrain the window of MSVC support to just "the two latest major releases" in future is also an attractive idea, as seen in some other big open source C/C++ projects, given our lack of Windows-native developers and reliance on CI, but let's call that a separate debate.)
On 05.06.25 12:42, Thomas Munro wrote: > I think on your C11 thread I might have been confused about that, > since there was an implication that 2019 might support <stdatomic.h>, > but it looks like 2019 added language stuff while 2022 added the > library stuff. But yeah, given your proposal that MSVC 2019 should be > our new minimum target on that platform, I wonder if we should have > both available in CI somehow... It would be useful to have a leading and a trailing edge CI system for every OS family. For example, say, Ubuntu 25.04 and RHEL 7, and VS 201x and VS 202y. Because as we are seeing here, sometimes you're more concerned about breaking the old one, and sometimes you're more interested in using a feature on the new one. Maybe one of the two could be manually triggered to save on resources.