Re: buildfarm / handling (undefined) locales

On 05/14/2014 05:19 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>> On 05/14/2014 12:07 AM, Tom Lane wrote:
>>> Well, all we know is that we asked setlocale for the default locale from
>>> the environment and it failed.  We don't really know which variable(s)
>>> it looked at.
>
>> Printing the values of the environment variables sounds complicated, but
>> I think a generic hint along these lines would be good:
>
>> initdb: environment locale settings are invalid
>> HINT: This usually means that the LANG, LC_ALL or LC_* environment
>> variable has an invalid value.
>
> Hm.  Keep in mind this is not backend code so we don't have a HINT
> formalism.  How about
>
> initdb: invalid locale settings; check LANG and LC_* environment variables

Works for me. I note that we have used the HINT: wording in pg_ctl, too:

pg_ctl: server does not shut down
HINT: The "-m fast" option immediately disconnects sessions rather than
waiting for session-initiated disconnection.

That's the only client program that does that, though, so perhaps we 
want to reconsider that in pg_ctl.

> Anyway, given that we seem to have consensus on doing this (modulo
> exact text of the error message), the next question is whether we
> want to change this only in HEAD, or consider it a back-patchable
> bug fix.  I lean to the former but can see that there's some
> argument for the latter.

HEAD-only. There might be scripts out there that do initdb with invalid 
LANG. They might be perfectly happy with getting the C locale, and 
backpatching this would make them unhappy.

- Heikki