Content-Type: multipart/mixed; boundary="------------k7VmMCaDUKf8Vx2x6OT7mmhy"
Message-ID: <70926239-1062-41c6-a831-f29b215d57bb@gmail.com>
Date: Wed, 1 Apr 2026 00:24:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: pgsql-hackers <pgsql-hackers@postgresql.org>
From: Bryan Green <dbryan.green@gmail.com>
Subject: [PATCH] BUG: Stale LC_MESSAGES translations after SET on windows.
Archived-At: 
 <https://www.postgresql.org/message-id/70926239-1062-41c6-a831-f29b215d57bb%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------k7VmMCaDUKf8Vx2x6OT7mmhy
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Greetings hackers,

The libintl library provides a libintl_setlocale function that we need
to use to correctly invalidate the libintl translation cache.  We are
not doing this as the following shows.

On Windows, changing lc_messages at runtime via SET returns stale
translations from the previous locale.  For example:

    SET lc_messages = 'de_DE';
    SELECT 1/0;
    -- FEHLER:  Division durch Null   (correct, German)

    SET lc_messages = 'en_US';
    SELECT 1/0;
    -- FEHLER:  Division durch Null   (wrong, still German)

libintl caches translated messages in a binary tree keyed by (msgid,
domain, category). The key struct includes a counter and a pointer to
the translation text and translation length in the mmap'd .mo file for
that locale.

Background:
Assume you have ("PL/pgSQL function %s line %d at %s",
"plpgsql-19",1729) for (msgid, domain, category) respectively.  Gettext
uses strcmp for msgid and domain, and integer subtraction for category
as it's comparison function. The search through the tree will short
circuit at a node as soon as one of the three-- compared left to right
as listed in the tuple-- is not a match.  If the comparison is negative
then it goes left in the tree, positive it goes right.  If all three
components of the key match then it checks that the counter matches
_nl_msg_cat_cntr.  If the counter matches then it is a cache hit.  If
the counter does not match then this translation was stored in the cache
before the current locale was set with libintl_setlocale-- in other
words it is stale. In this case the cache is invalidated and it is a
cache miss because the locale has changed.

Notice locale is not directly involved in the key structure for windows.
 So, if you don't increment the counter by calling libintl_setlocale and
the two locales have the same msgid's for a given domain you will get
the problem shown at the beginning of this email.


The fix adds an explicit call to libintl_setlocale(LC_MESSAGES, ...)
in pg_perm_setlocale() after IsoLocaleName() has produced the POSIX
name.  Instead of an explicit call, we could define
_INTL_REDIRECT_MACROS before including libintl.h in c.h.  This would
make all setlocale() calls go through libintl_setlocale on MSVC.  I
chose to be explicit to limit the blast radius.  The attached patch
limits the change to a single spot and resolves the identified bug.


Patch attached.

-- 
Bryan Green
EDB: https://www.enterprisedb.com

--------------k7VmMCaDUKf8Vx2x6OT7mmhy
Content-Type: text/plain; charset=UTF-8;
 name="v1-0001-Fix-stale-LC_MESSAGES-translations.patch"
Content-Disposition: attachment;
 filename="v1-0001-Fix-stale-LC_MESSAGES-translations.patch"
Content-Transfer-Encoding: base64

RnJvbSBiZTUzYTZlNjBjOWExZDQ2ZTM3OTdiZmZjNjA0ODE2MzI0ZmRmNjE2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBCcnlhbiBHcmVlbiA8ZGJyeWFuLmdyZWVuQGdtYWls
LmNvbT4KRGF0ZTogVHVlLCAzMSBNYXIgMjAyNiAyMDoxNDoxMiAtMDUwMApTdWJqZWN0OiBb
UEFUQ0ggdjFdIEZpeCBzdGFsZSBMQ19NRVNTQUdFUyB0cmFuc2xhdGlvbnMgYWZ0ZXIgU0VU
IG9uIFdpbmRvd3MuCgpPbiBXaW5kb3dzLCBwZ19wZXJtX3NldGxvY2FsZSgpIHNraXBzIGNh
bGxpbmcgc2V0bG9jYWxlKCkgZm9yCkxDX01FU1NBR0VTIGJlY2F1c2UgdGhlIE1TVkMgcnVu
dGltZSBkb2Vzbid0IHN1cHBvcnQgdGhhdCBjYXRlZ29yeS4KSW5zdGVhZCBpdCBzZXRzIHRo
ZSBMQ19NRVNTQUdFUyBlbnZpcm9ubWVudCB2YXJpYWJsZSBkaXJlY3RseS4KVGhpcyBtZWFu
cyBsaWJpbnRsJ3MgdHJhbnNsYXRpb24gY2FjaGUgKF9ubF9tc2dfY2F0X2NudHIpIGlzIG5l
dmVyCmludmFsaWRhdGVkLCBzbyBTRVQgbGNfbWVzc2FnZXMgYXQgcnVudGltZSByZXR1cm5z
IHN0YWxlIHRyYW5zbGF0aW9ucwpmcm9tIHRoZSBwcmV2aW91cyBsb2NhbGUuCgpGaXggYnkg
Y2FsbGluZyBsaWJpbnRsX3NldGxvY2FsZSgpIGRpcmVjdGx5IGFmdGVyIElzb0xvY2FsZU5h
bWUoKQpoYXMgcHJvZHVjZWQgdGhlIFBPU0lYIGxvY2FsZSBuYW1lLgoKQXV0aG9yOiBCcnlh
biBHcmVlbgotLS0KIHNyYy9iYWNrZW5kL3V0aWxzL2FkdC9wZ19sb2NhbGUuYyB8IDExICsr
KysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdp
dCBhL3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9wZ19sb2NhbGUuYyBiL3NyYy9iYWNrZW5kL3V0
aWxzL2FkdC9wZ19sb2NhbGUuYwppbmRleCA2YzVjMTAxOWUxLi5jZWEzZDFlNzE2IDEwMDY0
NAotLS0gYS9zcmMvYmFja2VuZC91dGlscy9hZHQvcGdfbG9jYWxlLmMKKysrIGIvc3JjL2Jh
Y2tlbmQvdXRpbHMvYWR0L3BnX2xvY2FsZS5jCkBAIC0yMzcsNiArMjM3LDE3IEBAIHBnX3Bl
cm1fc2V0bG9jYWxlKGludCBjYXRlZ29yeSwgY29uc3QgY2hhciAqbG9jYWxlKQogCQkJaWYg
KHJlc3VsdCA9PSBOVUxMKQogCQkJCXJlc3VsdCA9IChjaGFyICopIGxvY2FsZTsKIAkJCWVs
b2coREVCVUczLCAiSXNvTG9jYWxlTmFtZSgpIGV4ZWN1dGVkOyBsb2NhbGU6IFwiJXNcIiIs
IHJlc3VsdCk7CisKKwkJCS8qCisJCQkgKiBVc2UgdGhlIGxpYmludGxfc2V0bG9jYWxlIGZ1
bmN0aW9uIHByb3ZpZGVkIGJ5IGxpYmludGwgc28KKwkJCSAqIGl0IGludmFsaWRhdGVzIGl0
cyB0cmFuc2xhdGlvbiBjYWNoZSAoX25sX21zZ19jYXRfY250cikgYXMKKwkJCSAqIG5lZWRl
ZC4gIFdpdGhvdXQgdGhpcywgcmVzZXR0aW5nIGxjX21lc3NhZ2VzIHRvIGEgZGlmZmVyZW50
CisJCQkgKiBsb2NhbGUgYXQgcnVudGltZSByZXR1cm5zIHN0YWxlIHRyYW5zbGF0aW9ucyBm
cm9tIHRoZQorCQkJICogcHJldmlvdXMgbG9jYWxlLgorCQkJICovCisjaWZkZWYgRU5BQkxF
X05MUworCQkJKHZvaWQpIGxpYmludGxfc2V0bG9jYWxlKExDX01FU1NBR0VTLCByZXN1bHQp
OworI2VuZGlmCiAjZW5kaWYJCQkJCQkJLyogV0lOMzIgKi8KIAkJCWJyZWFrOwogI2VuZGlm
CQkJCQkJCS8qIExDX01FU1NBR0VTICovCi0tIAoyLjUyLjAud2luZG93cy4xCgo=

--------------k7VmMCaDUKf8Vx2x6OT7mmhy--