By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,541 Members | 1,476 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,541 IT Pros & Developers. It's quick & easy.

LC_COLLATE=C not working

P: n/a
I have two Linux servers, one is test and one is production. I run Postgres7.3.3 on both of them. I added a feature to my product that requires sorting like strcmp. So, I did an initdb as follows:

export LC_COLLATE=C
initdb

It fixed the sorting problem.

I have tried to do the same on my production server, and when I do the initdb, it says that LC_COLLATE is C, but it does not sort the same as the testserver. Namely, on the test server 'z' < '~' and on the production server 'z' > '~'.

Both servers have /usr/share/locale/C/cups_C, and they are identical.

Can anyone explain to me how to get Postgres to use LC_COLLATE=C on my production server? I have tried installing Postgres 7.3.3 RPM's for RedHat 7.3 and 8.0 and even tried Postgres 7.3.4 (for 8.0). Everything sorts the same as en_US.iso885915.

Thanks in advance.

Robert

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Robert Wille writes:
I have tried to do the same on my production server, and when I do the
initdb, it says that LC_COLLATE is C, but it does not sort the same as
the test server. Namely, on the test server 'z' < '~' and on the
production server 'z' > '~'.


You probably still have LC_ALL set to something else. LC_ALL overrides
LC_COLLATE and friends, which in turn override LANG.

--
Peter Eisentraut pe*****@gmx.net
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #2

P: n/a
> Robert Wille writes:
I have tried to do the same on my production server, and when I do the
initdb, it says that LC_COLLATE is C, but it does not sort the same as
the test server. Namely, on the test server 'z' < '~' and on the
production server 'z' > '~'.


You probably still have LC_ALL set to something else. LC_ALL overrides
LC_COLLATE and friends, which in turn override LANG.

--
Peter Eisentraut pe*****@gmx.net

Nope. Any other ideas?

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #3

P: n/a
"Robert Wille" <vm*******@sneakemail.com> writes:
You probably still have LC_ALL set to something else. LC_ALL overrides
LC_COLLATE and friends, which in turn override LANG.
Nope. Any other ideas?


Please use pg_controldata to verify the LC_ settings on both databases.
I suspect they are not really both C.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #4

P: n/a
pg_controldata $PGDATA says LC_COLLATE=C
pg_controldata $PGDATA/data says LC_COLLATE=en_US.iso885915

Perhaps this is a related problem. When I run dbinit, it puts a bunch of
configuration stuff in $PGDATA. When I start the postmaster, it tells me it
is initializing the database and creates $PGDATA/data and puts the same
configuration stuff there. I have no idea why it creates two sets of
configuration data. I don't see this on my test server, just on my
production server. My guess is that when it initializes the database when
the postmaster starts, that it isn't getting the LC_COLLATE setting.

----- Original Message -----
From: "Tom Lane tgl-at-sss.pgh.pa.us |Postgres|"
<xf**********@sneakemail.com>
To: "Robert Wille" <ro*****@willeweb.com>
Cc: "Peter Eisentraut peter_e-at-gmx.net |Postgres|"
<46**********@sneakemail.com>; <pg***********@postgresql.org>
Sent: Friday, October 03, 2003 9:35 AM
Subject: Re: [GENERAL] LC_COLLATE=C not working

"Robert Wille" <vm*******@sneakemail.com> writes:
You probably still have LC_ALL set to something else. LC_ALL overrides
LC_COLLATE and friends, which in turn override LANG.

Nope. Any other ideas?


Please use pg_controldata to verify the LC_ settings on both databases.
I suspect they are not really both C.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.