buildfarm / handling (undefined) locales

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: buildfarm / handling (undefined) locales
Date: 2014-05-13 18:27:03
Message-ID: 537263F7.7090705@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

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".

Yeah, not really what we were shooting for. I've fixed this by defining
the missing locales, and indeed - magpie now fails in plpython tests.

Now, the question is - is this a pilot error or should we check this
somehow? For example a simple check whether server_encoding/lc_* seems
like a good idea (although I wonder whether the fallback logic in initdb
is really a good idea).

regards
Tomas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-05-13 18:39:59 Re: buildfarm / handling (undefined) locales
Previous Message Jeff Janes 2014-05-13 18:19:54 Re: Wanna help PostgreSQL