Hello,
finally the problem is solved. The problem was with locales.
I installed and initialised the database under cs_CZ, so Pg
recorded cs_CZ in all its configurations and startup scripts.
After that I changed /etc/sysconfig/i18n to use en_US locale as
system default.
And that was the problem. According to "ps axe" the postmaster was
running under en_US locales instead of cs_CZ as I expected.
So I changed /etc/sysconfig/i18n to use cs_CZ and everything is ok
from then. All indexes seem to be working fine and there are no problems.
But I would like to know why it was not started under cs_CZ when
all Pg config files specify cs_CZ and ~postgres/.bash_profile contains
export LANG="cs_CZ" and postmaster is run from it's rc script as
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl -D $PGDATA ...."
So I expected that cs_CZ will be used in this case. :-( GRrrrrr.
Ok now it's working, thank you all who helped.
Martin
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > Martin, you can probably rule out the cs_CZ (LATIN2) locale as the cause
> > of your problems -- I've been using that one for years on many production
> > postgres systems (often huge and constantly loaded) and have never observed
> > the problems you're describing.
>
> Thanks for the info. But are you using cs_CZ.ISO8859-2 in particular on
> Red Hat 8.0 in particular? If it is a locale-related issue, it might be
> specific to that particular variant on that platform.
>
> I have RH 8.0 here, and could easily run some tests, but I'm not sure
> what to look for. A quick run of the regression tests didn't reveal
> any issues, other than expectable differences from C locale in sort
> ordering.
>
> regards, tom lane
>
--
Martin Edlman
Fortech s.r.o, Litomysl
Public PGP key: http://edas.visaci.cz/#keys
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
