Re: Multicolumn index corruption on 8.4 beta 2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Multicolumn index corruption on 8.4 beta 2
Дата
Msg-id 11966.1244662964@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Multicolumn index corruption on 8.4 beta 2  (Floris Bos / Maxnet <bos@je-eigen-domein.nl>)
Список pgsql-hackers
Floris Bos / Maxnet <bos@je-eigen-domein.nl> writes:
> Hi,
> Tom Lane wrote:
>> Floris Bos / Maxnet <bos@je-eigen-domein.nl> writes:
>>> postgres@db:/data$ /opt/postgres/8.4-beta/bin/64/initdb -E SQL_ASCII -X 
>>> /data/pg_xlog /data/db
>>> The database cluster will be initialized with locale en_US.UTF-8.
>> 
>> Oooh, that doesn't look real good.  You're going to be using strcoll()
>> comparisons that assume the data is in UTF8, but the database is not
>> enforcing valid UTF8 encoding.  I have not checked the dump to see if
>> it's all valid data, but this could be the root of the issue.
>> 
>> If you want to use SQL_ASCII because the data isn't uniformly encoded,
>> it'd be better to use C locale.

> Darn.
> Looks like you are right!
> Works a lot better with "--locale=C"

> My 8.3 PostgreSQL installation ran under FreeBSD, and there the locale 
> is C by default:
> So I was not used to have to add a "--locale=C" option.
> Under Opensolaris it's indeed UTF-8 by default.

Yeah, this is kind of unfortunate.  I'm not sure there is much we could
do about it, unless we want to insist that C locale be used if the
database encoding is SQL_ASCII.  That cure seems worse than the disease
though.  We have locked down encoding/locale combinations pretty
strictly for 8.4, but SQL_ASCII is generally thought to be a "let the
user beware" setting.
        regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pgindent run coming
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgindent run coming