Re: PRI?64 vs Visual Studio (2022)

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
suchfile or directory) 
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C.utf8/LC_MESSAGES/regress-19.mo", O_RDONLY) = -1 ENOENT (No
suchfile 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
(Nosuch file or directory) 
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C.utf8/LC_MESSAGES/postgres-19.mo", O_RDONLY) = -1 ENOENT (No
suchfile or directory) 
openat(AT_FDCWD, "/home/postgres/testversion/share/locale/C/LC_MESSAGES/postgres-19.mo", O_RDONLY) = -1 ENOENT (No such
fileor 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