BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw

On Fri, May 30, 2025 at 7:42 AM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 18940
Logged by: Joe Ayers
Email address: joseph.ayers@crunchydata.com
PostgreSQL version: 18beta1
Operating system: Windows Server 2022
Description:

Hey there!
In working on some test builds, PostgreSQL 18beta1 is failing the
'collate.windows.win1252' regression test due to missing locales. When
building with MYS2/mingw (Tested Windows Server 2022 and Windows Server
2019), default locale that's pulled in is typically 'american_usa' as
opposed to 'en_US', which causes the test to fail citing:
+ERROR:  could not create locale "en-US": No such file or directory
+DETAIL:  The operating system could not find any locale data for the
locale name "en-US".
The above error is repeated several times. Hoping to learn how to adjust the
config to get this to pass, as the error did not occur for PG17 and below.
Any info is appreciated.
I can attach the full regression.diffs file for additional information if it
would be of help.

Huh. It passes on our CI:

https://cirrus-ci.com/task/4738549062303744

And on our build farm machine:

https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren&amp;br=master

I wonder what is different. Are you using ucrt? We started removing
bits and pieces related to the old msvcrt C runtime, but my
understanding is that msys2 compile should target ucrt by default.

On Wed, Jun 4, 2025 at 4:40 AM Thomas Munro <thomas.munro@gmail.com> wrote:

On Fri, May 30, 2025 at 7:42 AM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 18940
Logged by: Joe Ayers
Email address: joseph.ayers@crunchydata.com
PostgreSQL version: 18beta1
Operating system: Windows Server 2022
Description:

Hey there!
In working on some test builds, PostgreSQL 18beta1 is failing the
'collate.windows.win1252' regression test due to missing locales. When
building with MYS2/mingw (Tested Windows Server 2022 and Windows Server
2019), default locale that's pulled in is typically 'american_usa' as
opposed to 'en_US', which causes the test to fail citing:
+ERROR:  could not create locale "en-US": No such file or directory
+DETAIL:  The operating system could not find any locale data for the
locale name "en-US".
The above error is repeated several times. Hoping to learn how to adjust

the

config to get this to pass, as the error did not occur for PG17 and

below.

Any info is appreciated.
I can attach the full regression.diffs file for additional information

if it

would be of help.

Huh. It passes on our CI:

https://cirrus-ci.com/task/4738549062303744

And on our build farm machine:

https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren&amp;br=master

I wonder what is different. Are you using ucrt? We started removing
bits and pieces related to the old msvcrt C runtime, but my
understanding is that msys2 compile should target ucrt by default.

(Forgot to reply-all, apologies)

We're using the mingw64 toolchain for this. I think per the MSYS
environments guide here: https://www.msys2.org/docs/environments/
that this would mean we're using msvcrt and not ucrt? That may be the
issue. Would we maybe have to move to a different kind of MSYS environment?

Thanks!

--
-------
Joe Ayers
Crunchy Data
www.crunchydata.com

Hi,

On 2025-06-04 09:28:15 -0700, Joseph Ayers wrote:

On Wed, Jun 4, 2025 at 4:40 AM Thomas Munro <thomas.munro@gmail.com> wrote:

On Fri, May 30, 2025 at 7:42 AM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 18940
Logged by: Joe Ayers
Email address: joseph.ayers@crunchydata.com
PostgreSQL version: 18beta1
Operating system: Windows Server 2022
Description:

Hey there!
In working on some test builds, PostgreSQL 18beta1 is failing the
'collate.windows.win1252' regression test due to missing locales. When
building with MYS2/mingw (Tested Windows Server 2022 and Windows Server
2019), default locale that's pulled in is typically 'american_usa' as
opposed to 'en_US', which causes the test to fail citing:
+ERROR:  could not create locale "en-US": No such file or directory
+DETAIL:  The operating system could not find any locale data for the
locale name "en-US".
The above error is repeated several times. Hoping to learn how to adjust

the

config to get this to pass, as the error did not occur for PG17 and

below.

Any info is appreciated.
I can attach the full regression.diffs file for additional information

if it

would be of help.

Huh. It passes on our CI:

https://cirrus-ci.com/task/4738549062303744

And on our build farm machine:

https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren&amp;br=master

I wonder what is different. Are you using ucrt? We started removing
bits and pieces related to the old msvcrt C runtime, but my
understanding is that msys2 compile should target ucrt by default.

(Forgot to reply-all, apologies)

We're using the mingw64 toolchain for this. I think per the MSYS
environments guide here: https://www.msys2.org/docs/environments/
that this would mean we're using msvcrt and not ucrt? That may be the
issue. Would we maybe have to move to a different kind of MSYS environment?

I would *strongly* advise to moving to ucrt. Personally I think we should just
refuse to build with msvcrt.

Greetings,

Andres Freund

On Wed, Jun 4, 2025 at 9:32 AM Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2025-06-04 09:28:15 -0700, Joseph Ayers wrote:

On Wed, Jun 4, 2025 at 4:40 AM Thomas Munro <thomas.munro@gmail.com>

wrote:

On Fri, May 30, 2025 at 7:42 AM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 18940
Logged by: Joe Ayers
Email address: joseph.ayers@crunchydata.com
PostgreSQL version: 18beta1
Operating system: Windows Server 2022
Description:

Hey there!
In working on some test builds, PostgreSQL 18beta1 is failing the
'collate.windows.win1252' regression test due to missing locales.

When

building with MYS2/mingw (Tested Windows Server 2022 and Windows

Server

2019), default locale that's pulled in is typically 'american_usa' as
opposed to 'en_US', which causes the test to fail citing:
+ERROR: could not create locale "en-US": No such file or

directory

+DETAIL: The operating system could not find any locale data

for the

locale name "en-US".
The above error is repeated several times. Hoping to learn how to

adjust

the

config to get this to pass, as the error did not occur for PG17 and

below.

Any info is appreciated.
I can attach the full regression.diffs file for additional

information

if it

would be of help.

Huh. It passes on our CI:

https://cirrus-ci.com/task/4738549062303744

And on our build farm machine:

https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren&amp;br=master

I wonder what is different. Are you using ucrt? We started removing
bits and pieces related to the old msvcrt C runtime, but my
understanding is that msys2 compile should target ucrt by default.

(Forgot to reply-all, apologies)

We're using the mingw64 toolchain for this. I think per the MSYS
environments guide here: https://www.msys2.org/docs/environments/
that this would mean we're using msvcrt and not ucrt? That may be the
issue. Would we maybe have to move to a different kind of MSYS

environment?

I would *strongly* advise to moving to ucrt. Personally I think we should
just
refuse to build with msvcrt.

Greetings,

Andres Freund

Thanks for the responses here! Working on switching to UCRT64 for PG18+
builds. Making the switch appears to get the Locale regression to pass.

Thanks again!
--
-------
Joe Ayers
Crunchy Data
www.crunchydata.com

On Thu, Jun 5, 2025 at 4:32 AM Andres Freund <andres@anarazel.de> wrote:

I would *strongly* advise to moving to ucrt. Personally I think we should just
refuse to build with msvcrt.

Yeah, I didn't realise that it'd still build but not work correctly,
so +1 for adding an #error like the attached. The attached passed on
CI in the MinGW and Visual Studio tasks (and in passing removes some
more trace of msvcrt), but the Debian cross-compilation step helpfully
shows how it fails with an msvcrt build:

https://cirrus-ci.com/task/4559077411389440

It cross-builds successfully on my local Debian system after
installing these packages:

gcc-mingw-w64-ucrt64
g++-mingw-w64-ucrt64

... and selecting those compilers, as shown in the attached fixup. So
I think we'll first need to get them added to the CI image, in here:

https://github.com/anarazel/pg-vm-images/blob/main/scripts/linux_debian_install_deps.sh

And then we could push something like this.

On Sat, Jun 7, 2025 at 12:17 AM Thomas Munro <thomas.munro@gmail.com> wrote:

It cross-builds successfully on my local Debian system after
installing these packages:

gcc-mingw-w64-ucrt64
g++-mingw-w64-ucrt64

... and selecting those compilers, as shown in the attached fixup. So
I think we'll first need to get them added to the CI image, in here:

https://github.com/anarazel/pg-vm-images/blob/main/scripts/linux_debian_install_deps.sh

And then we could push something like this.

I tried to make the pull request for that and learned that those
packages don't exist in Debian 12 (bookworm) as used on CI. I'd
tested locally on Debian 13 (trixie). So maybe we have to wait a
short time for trixie to become the new Debian stable release (due any
time soon AFAIK), then update CI to trixie, and then we can do that.
Unless someone knows better.