Re: buildfarm / handling (undefined) locales

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: buildfarm / handling (undefined) locales
Date: 2014-05-13 19:48:16
Message-ID: 53727700.1050104@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/13/2014 09:58 PM, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> a few days ago I switched magpie into an LXC container, and while
>> fixinig unrelated issue there, I noticed that although the tests seemed
>> to run, some of the results are actually rubbish because of missing locales.
>
>> So for example when the system misses cs_CZ.WIN-1250 (i.e. czech locale
>> with windows codepage 1250), initdb actually did this
>
>> The files belonging to this database system will be owned by user
>> "pgbuild".
>> This user must also own the server process.
>
>> initdb: invalid locale name ""
>> initdb: invalid locale name ""
>> initdb: invalid locale name ""
>> initdb: invalid locale name ""
>> initdb: invalid locale name ""
>> initdb: invalid locale name ""
>> The database cluster will be initialized with locale "C".
>> The default database encoding has accordingly been set to
>> "SQL_ASCII".
>> The default text search configuration will be set to "english".
>
> Hm, I'm a bit confused as to what you actually did here. The "invalid
> locale name" bleats seem to indicate that no --locale or --lc_xxx options
> were given on the command line; correct? If so the issue is presumably
> that the environment variable(s) were set to incorrect values. While
> we *could* abort in that situation, I've never heard of any program
> that did; the normal response is to silently ignore the environment
> variables and use C locale. We're not being exactly silent about it
> but I think the outcome is the expected one.

Initdb isn't like most programs. The locale given to initdb is memorized
in the data directory, and if you later notice that it was wrong, you'll
have to dump and reload. There is a strong argument for initdb to be
more strict than, say, your average text editor.

> There is a comment in the code about this:
>
> /* should we exit here? */
> if (res == NULL)
> fprintf(stderr, _("%s: invalid locale name \"%s\"\n"),
> progname, locale);
>
> but I think what's being questioned is whether an incorrect locale
> name *given as a command line argument* should result in an abort.
> That might be a good idea, but it looks like it'd require some
> restructuring of the code to make it possible to distinguish the
> case from bad-environment.

Yeah, I think we should definitely complain and exit if the locale given
on the command-line is invalid.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-05-13 20:00:21 Re: buildfarm / handling (undefined) locales
Previous Message Rukh Meski 2014-05-13 19:45:23 Re: 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..