Re: "could not adopt C locale" failure at startup on Windows
От | Tom Lane |
---|---|
Тема | Re: "could not adopt C locale" failure at startup on Windows |
Дата | |
Msg-id | 9948.1433867042@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "could not adopt C locale" failure at startup on Windows (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: "could not adopt C locale" failure at startup on Windows
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2015-06-09 11:20:06 -0400, Tom Lane wrote: >> We've seen several reports of $SUBJECT lately. I have no idea what's >> going on, but it occurred to me that it could be informative to tweak >> init_locale() so that it reports which category failed to be set. >> Any objections to squeezing that into today's releases? > No objection, +1. Seems fairly low risk. > The error seems odd. The only even remotely related change between 9.4.1 > and .2 seems to be ca325941. Could also be a build environment change. Yeah, my first instinct was to blame ca325941 as well, but I don't think any of that code executes during init_locale(). Also, http://www.postgresql.org/message-id/20150326040321.2492.24716@wrigleys.postgresql.org says it's been seen in 9.4.1. Of course, it might be premature to assume that report had an identical cause to the later ones. What I plan to do is this: static void init_locale(const char *categoryname, int category, const char *locale) { if (pg_perm_setlocale(category, locale) == NULL && pg_perm_setlocale(category, "C") == NULL) elog(FATAL,"could not adopt either \"%s\" locale or C locale for %s", locale, categoryname); } with the obvious changes to the call sites to pass the string names of the categories not just their numeric codes. (We could just log the numbers, but it'd be much harder to interpret.) This might be overkill, but when you don't know what you're looking for, every little bit helps ... regards, tom lane
В списке pgsql-hackers по дате отправления: