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
