Re: buildfarm / handling (undefined) locales

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: buildfarm / handling (undefined) locales
Дата
Msg-id 53740818.3050401@fuzzy.cz
обсуждение исходный текст
Ответ на Re: buildfarm / handling (undefined) locales  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: buildfarm / handling (undefined) locales
Список pgsql-hackers
On 13.5.2014 23:07, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 05/13/2014 04:14 PM, Tom Lane wrote:
>>> But independently of whether it's a fatal error or not: when there's
>>> no relevant command-line argument then we print the
>>>
>>> invalid locale name ""
>>>
>>> message which is surely pretty unhelpful.  It'd be better if we could
>>> finger the incorrect environment setting.  Unfortunately, we don't know
>>> for sure which environment variable(s) setlocale was looking at --- I
>>> believe it's somewhat platform specific.  We could probably print
>>> something like this instead:
>>>
>>> environment locale settings are invalid
>>>
>>> Thoughts?
> 
>> I'd also be tempted to add the settings for LC_ALL and LANG and note 
>> that they are possible sources of the problem, or maybe only do that if 
>> they match the locale being rejected.
> 
> 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.  I think printing specific variables could easily be as
> misleading as it is helpful; and given the lack of prior complaints,
> I'm doubtful that it's worth going to the effort of trying to print a
> platform-specific collection of variables.
> 
> Attached is a draft patch that behaves like this:
> 
> $ initdb --locale=foo
> The files belonging to this database system will be owned by user "postgres".
> This user must also own the server process.
> 
> initdb: invalid locale name "foo"

I see the committed patch actually behaves like this:
 initdb: invalid locale name "cs_CZ.WIN-1250" The files belonging to this database system will be owned by user
"pgbuild".This user must also own the server process.
 

(at least that's what magpie logged at [1]). I find that confusing,
because initdb logs the actual problem and then two more lines so it
seems like nothing happened.

I think we should keep the message explaining the problem last, i.e. not
log the two additional messages (which are quite pointless), switch the
order of messages or add another one.

[1]
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=magpie&dt=2014-05-14%2019%3A20%3A25

Tomas



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Writing changes of decoding plugin in the memory context where data is kept?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm / handling (undefined) locales