Re: gai_strerror() is not thread-safe on Windows
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: thomas.munro@gmail.com
Cc: pgsql-hackers@postgresql.org
Date: 2023-12-05T02:43:42Z
Lists: pgsql-hackers
At Tue, 5 Dec 2023 08:26:54 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in > On second thoughts, I guess it would make more sense to use the exact > messages Windows' own implementation would return instead of whatever > we had in the past (probably cribbed from some other OS or just made > up?). I asked CI to spit those out[1]. Updated patch attached. Will > add to CF. > > [1] https://cirrus-ci.com/task/5816802207334400?logs=main#L15 Windows' gai_strerror outputs messages that correspond to the language environment. Similarly, I think that the messages that the messages returned by our version should be translatable. These messages may add extra line-end periods to the parent (or cotaining) messages when appended. This looks as follows. (auth.c:517 : errdetail_log() : sub (detail) message) > Could not translate client host name "hoge" to IP address: An address incompatible with the requested protocol was used.. (hba.c:1562 : errmsg() : main message) > invalid IP address "192.0.2.1": This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server. When I first saw the first version, I thought it would be better to use Windows' own messages, just like you did. However, considering the content of the message above, wouldn't it be better to adhere to Linux-style messages overall? A slightly subtler point is that the second example seems to have a misalignment between the descriptions before and after the colon, but do you think it's not something to be concerned about to this extent? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Fix gai_strerror() thread-safety on Windows.
- 0460e4ecc0fa 16.3 landed
- 65f438471b76 17.0 landed
-
Update comment, generation mem contexts have a "keeper" block
- 376c216138c7 17.0 cited
-
Remove replacement code for getaddrinfo.
- 5579388d2dda 16.0 cited