Upgrade from 7.4.5 to 8.3.3

I guess we don't have locale mapping for SCO OpenServer5.7. See
http://doxygen.postgresql.org/chklocale_8c-source.html

Could you run following code:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg01168.php

and send output.

Zdenek

Harvey, Allan AC napsal(a):

During an upgrade from 7.4.5 to 8.3.3 the following was dumped during the restore process from psql.

psql:roperydb_v7.4_20081021.dmp:49: WARNING: could not determine encoding for locale "C_C.C": codeset is ""
DETAIL: Please report this to <pgsql-bugs@postgresql.org>.

So I am reporting it.

Back ground.
I am using 8.3.3 because it is the latest I have for SCO OpenServer5.7

I used "pg_dumpall -o" from the 8.3.3 release.

During the "initdb" process similar errors were dumped and a suggestion of passng a locale with the -E option was used.
Explicitly I used:

/usr/local/pgsql/bin/initdb -E SQL_ASCII -D /usr/local/pgsql/data

which allowed the process to complete.

The warning above was then dumped during the restore process.

The cluster seems to working OK.

Should I be concerned?

Thanks for your time.

Allan

The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments.

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

Hmm, It does not look good. Your OS does not return proper information about
codeset. Following code is broken:

setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);

See
http://www.opengroup.org/onlinepubs/009695399/functions/nl_langinfo.html

It seems you need to fix OS first. After that we can add CODESET mapping to
PostgreSQL.

Zdenek

Harvey, Allan AC napsal(a):

Zdenek

Thanks for your reply.

I guess we don't have locale mapping for SCO OpenServer5.7. See
http://doxygen.postgresql.org/chklocale_8c-source.html

Browser Timed out. (?)

Could you run following code:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg01168.php

and send output.

Zdenek

Output as requested:

bash-2.05$ for LOCALE in `locale -a`; do locale_test $LOCALE; done
C_C.C ... - NO MATCH
cs_CZ.ISO8859-2 ... - NO MATCH
english_uk.ISO8859-15 ... - NO MATCH
english_uk.8859 ... - NO MATCH

<snip>

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

Zdenek,

Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:

setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);

See
http://www.opengroup.org/onlinepubs/009695399/functions/nl_lan

ginfo.html

It seems you need to fix OS first. After that we can add CODESET mapping to
PostgreSQL.

Zdenek

I don't think this is possible.

Can you give me an indication what problems I should look out for?
Regression testing only showed some date format issues if I remeber correctly.

Allan

Harvey, Allan AC napsal(a):

Zdenek

Thanks for your reply.

I guess we don't have locale mapping for SCO OpenServer5.7. See
http://doxygen.postgresql.org/chklocale_8c-source.html

Browser Timed out. (?)

Could you run following code:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg01168.php

and send output.

Zdenek

Output as requested:

bash-2.05$ for LOCALE in `locale -a`; do locale_test $LOCALE; done
C_C.C ... - NO MATCH
cs_CZ.ISO8859-2 ... - NO MATCH
english_uk.ISO8859-15 ... - NO MATCH
english_uk.8859 ... - NO MATCH

<snip>

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments.

Harvey, Allan AC wrote:

Zdenek,

Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:

setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);

See
http://www.opengroup.org/onlinepubs/009695399/functions/nl_lan

ginfo.html

It seems you need to fix OS first. After that we can add CODESET mapping to
PostgreSQL.

Zdenek

I don't think this is possible.

Can you give me an indication what problems I should look out for?

SQL_ASCII might work tolerably if all your clients use the same client
encoding.

Harvey, Allan AC napsal(a):

Zdenek,

Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:

setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);

See
http://www.opengroup.org/onlinepubs/009695399/functions/nl_lan

ginfo.html

It seems you need to fix OS first. After that we can add CODESET mapping to
PostgreSQL.

Zdenek

I don't think this is possible.

Can you give me an indication what problems I should look out for?
Regression testing only showed some date format issues if I remeber correctly.

I think, problem could be on two places:

1) libc is broken and does not return correct values.
2) locale definition does not contain CODESET information.

Do you use system libc or glibc? You can try create own locale by localedef and
test what happen.

Zdenek

Zdenek,

Harvey, Allan AC napsal(a):

Zdenek,

Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:

setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);

See
http://www.opengroup.org/onlinepubs/009695399/functions/nl_lan

ginfo.html

It seems you need to fix OS first. After that we can add

CODESET mapping to

PostgreSQL.

Zdenek

I don't think this is possible.

Can you give me an indication what problems I should look out for?
Regression testing only showed some date format issues if I

remeber correctly.

I think, problem could be on two places:

1) libc is broken and does not return correct values.
2) locale definition does not contain CODESET information.

Do you use system libc or glibc? You can try create own
locale by localedef and
test what happen.

Zdenek

I think it would have to be glibc as I used the gcc loaded with the "skunkware" tools that SCO provide.
To date I have had no operational problems, I guess it must be a relatively simple use of postgres.

So I thank you and all the others for their time and suggest that we let this one slide unless you really want to get to the bottom of it. I have the time, just not the understanding of "locale"s and the implications and implementations.

Allan

The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments.

Harvey, Allan AC wrote:

Do you use system libc or glibc? You can try create own
locale by localedef and
test what happen.

I think it would have to be glibc as I used the gcc loaded with the "skunkware" tools that SCO provide.

gcc may be, and often is, used with the system libc. It'd be much less
useful otherwise, since you generally can't link to more than one libc
without a great deal of trouble, and thus you couldn't use libraries
that were linked to the system libc with gcc if it could only use gcc.

If I recall correctly the gcc shipped in skunkware generates binaries
linked to the system libc. It should be trivial to find out by compiling
a "hello world" program and using /bin/ldd to show what it's linked to.

It might be possible to build PostgreSQL against glibc instead, but it
seems like way more work than would be worthwhile when you can just run
Pg on a modern machine and talk to it over the network.

--
Craig Ringer