From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bryan Green <dbryan.green@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: PRI?64 vs Visual Studio (2022)
Date: Mon, 15 Dec 2025 18:31:38 -0500
Message-ID: <2279213.1765841498@sss.pgh.pa.us> (raw)
In-Reply-To: <a337896e-5bff-490b-afc9-c545f06c014c@gmail.com>
References: <20250331.152829.1921392690375275165.horikyota.ntt@gmail.com>
<001bdc3b-ef94-4f24-b017-ac8ff0a2ea55@eisentraut.org>
<CA+hUKGJnmzTqiODmTjf-23yZ=E3HXqFTtKoyp3TF-MpB93hTMQ@mail.gmail.com>
<1372793.1763519315@sss.pgh.pa.us>
<CA+hUKGLzXzQcbjEHW08Z6g=mzBkpLtzSJ7Bt2S2XmxP1bwpq8A@mail.gmail.com>
<1377512.1763522154@sss.pgh.pa.us>
<e7b902aa-98ac-4d35-bae3-d7d282a938c2@eisentraut.org>
<1462038.1763567038@sss.pgh.pa.us>
<CA+hUKG+nMv9bmOcARaDFC6rG=SGWC=TwWSRLrxi29oGeRNKemg@mail.gmail.com>
<1881391.1765782112@sss.pgh.pa.us>
<CA+hUKGJaX3AcuKSdEUOZiWc+mzL=+dvGnbMqCvWGY22y6oh9Nw@mail.gmail.com>
<1991599.1765818338@sss.pgh.pa.us>
<c6379076-aabc-4ee8-920b-bd0d18bd2379@gmail.com>
<2117910.1765823286@sss.pgh.pa.us>
<b7d99342-07c3-4d50-af1d-a7b58d2631bd@gmail.com>
<2128694.1765826341@sss.pgh.pa.us>
<2259481.1765831157@sss.pgh.pa.us>
<a337896e-5bff-490b-afc9-c545f06c014c@gmail.com>
Bryan Green <dbryan.green@gmail.com> writes:
> On 12/15/2025 2:39 PM, Tom Lane wrote:
>> Hmmm ... the first batch of BF reports show that on some Linux
>> machines, it works to set lc_messages to 'C.UTF-8', but nonetheless
>> no translation happens. Did you notice any other gating factors?
> Yes - the LANGUAGE environment variable.
Not it, I think. pg_regress unsets that. Also, I've been able to
reproduce the failure here using a Fedora 42 image, and LANGUAGE
is definitely not set in that environment.
> Do we know what version of libintl is being used on those BF machines?
> There are some marked differences between some versions, which makes
> this a little more guesswork than it should be.
On my Fedora image, there seems to be no libintl.so anywhere; it's
certainly not getting linked into Postgres. The routines must be
built into libc. rpm says the glibc version is
glibc-2.41-11.fc42.x86_64. Judging by buildfarm reports, the
behavior changed sometime between Fedora 39 and Fedora 42.
strace'ing shows that during "SET lc_messages = 'C.UTF-8'",
it successfully finds system locale data about C.utf8:
recvfrom(10, "Q\0\0\0!SET lc_messages = 'C.UTF-8'"..., 8192, 0, NULL, NULL) = 34
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 21
fstat(21, {st_mode=S_IFREG|0644, st_size=217804320, ...}) = 0
mmap(NULL, 217804320, PROT_READ, MAP_PRIVATE, 21, 0) = 0x7f935c5f6000
close(21) = 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 21
fstat(21, {st_mode=S_IFREG|0644, st_size=2997, ...}) = 0
read(21, "# Locale name alias data base.\n#"..., 4096) = 2997
read(21, "", 4096) = 0
close(21) = 0
openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 21
fstat(21, {st_mode=S_IFDIR|0755, st_size=29, ...}) = 0
close(21) = 0
openat(AT_FDCWD, "/usr/lib/locale/C.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 21
fstat(21, {st_mode=S_IFREG|0644, st_size=53, ...}) = 0
mmap(NULL, 53, PROT_READ, MAP_PRIVATE, 21, 0) = 0x7f937690a000
close(21) = 0
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 21
fstat(21, {st_mode=S_IFREG|0644, st_size=26998, ...}) = 0
mmap(NULL, 26998, PROT_READ, MAP_SHARED, 21, 0) = 0x7f9376903000
close(21) = 0
futex(0x7f93752999a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
sendto(10, "C\0\0\0\10SET\0Z\0\0\0\5I", 15, 0, NULL, 0) = 15
This part of the trace seems indistinguishable between an older
RHEL system and Fedora 42. But on the older system, when we
invoke pg_bindtextdomain, it does open the regress-19.mo file:
recvfrom(10, "Q\0\0\0\37SELECT test_translation();\0", 8192, 0, NULL, NULL) = 32
stat("/home/postgres/pgsql/src/test/regress/regress.so", {st_mode=S_IFREG|0775, st_size=264904, ...}) = 0
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C.UTF-8/LC_MESSAGES/regress-19.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C.utf8/LC_MESSAGES/regress-19.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C/LC_MESSAGES/regress-19.mo", O_RDONLY) = 21
fstat(21, {st_mode=S_IFREG|0644, st_size=2316, ...}) = 0
mmap(NULL, 2316, PROT_READ, MAP_PRIVATE, 21, 0) = 0x7f9376902000
close(21) = 0
brk(NULL) = 0x1a52000
brk(0x1a75000) = 0x1a75000
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C.UTF-8/LC_MESSAGES/postgres-19.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C.utf8/LC_MESSAGES/postgres-19.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C/LC_MESSAGES/postgres-19.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
and away we go. On the newer system, there is no attempt to access
the .mo file at all. It looks like it's decided that C.UTF-8 isn't
really a valid locale and it's just going to ignore everything.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, dbryan.green@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: PRI?64 vs Visual Studio (2022)
In-Reply-To: <2279213.1765841498@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox