Thread
-
BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
PG Bug reporting form <noreply@postgresql.org> — 2025-05-29T16:59:18Z
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. Thank you! -
Re: BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
Thomas Munro <thomas.munro@gmail.com> — 2025-06-04T11:39:51Z
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&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.
-
Re: BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
Joseph Ayers <joseph.ayers@crunchydata.com> — 2025-06-04T16:28:15Z
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&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
-
Re: BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
Andres Freund <andres@anarazel.de> — 2025-06-04T16:32:44Z
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&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
-
Re: BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
Joseph Ayers <joseph.ayers@crunchydata.com> — 2025-06-05T23:08:20Z
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&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
-
Re: BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
Thomas Munro <thomas.munro@gmail.com> — 2025-06-06T12:17:32Z
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.
-
Re: BUG #18940: PostgreSQL 18beta1 fails 'collate.windows.win1252' regression when building with MSYS/mingw
Thomas Munro <thomas.munro@gmail.com> — 2025-06-07T10:11:09Z
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.