Re: Crash

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Crash
Дата
Msg-id 9719.984608789@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: Crash  ("John W Cunningham" <john@pickaprof.com>)
Список pgsql-admin
"John W Cunningham" <john@pickaprof.com> writes:
> I ran the test - can anyone tell me what these results mean and how I can
> fix it?

The diffs look like locale issues --- specifically, I'd say that your
server is running in en_US or some other locale with ISO-like sorting
rules for strings.

I am now wondering if your original problem
    ERROR:  cannot find attribute 1 of relation pg_proc_oid_index
might also be a locale issue.  Specifically, if the server was initdb'd
with one locale but is now being run in another, it could be suffering
from apparent index corruption (because the indexes are not in order
according to its current idea of what ordering means).  If this is
happening in the system indexes then you've got big problems.

Release 7.1 will have defenses against this common error, but in earlier
releases it's critical to ensure that every postmaster start has the
same locale environment variables as were seen by initdb.  That's *real*
easy to get wrong, since initdb is normally done by hand while the
postmaster is commonly started from boot scripts (which won't have the
exact same environment a login shell has).

I'd suggest discussing this with your ISP --- they probably need to redo
the initdb under the same locale that the postmaster will routinely run
under.  It's usually a smart idea to set the locale environment (LANG
or LC_ALL) explicitly in the script that launches the postmaster.

BTW, if you don't actually *need* any locale-sensitive processing, a
good way to avoid the whole problem is to build the software without
locale support.

            regards, tom lane

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

Предыдущее
От: "John W Cunningham"
Дата:
Сообщение: RE: Crash
Следующее
От: Gunnar Lindholm
Дата:
Сообщение: Postgresql limits