FW: [ADMIN] Strange client encoding issue
am 17.01.2008 18:49:01 von Benjamin Krajmalnik
I posted this info in ADMIN.
Any insight from the ODBC core team will be appreciated.
Thi is not causing problems in the actual data, since there is no Latin9
data and technically Latin9 is a superset of Latin1. I was just
wondering what can be causing the ODBC driver to issue a set
client_encoding to 'latin9' implicitly.
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Benjamin
Krajmalnik
Sent: Wednesday, January 16, 2008 10:17 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Strange client encoding issue
Additional info:
Thanks to Tom Lane, who pointed me in the right direction concerning the
logging to identify the connection creating the problem.
The error is most definitely being generated by the ODBC connection.
What can be causing the ODBC driver to set the client encoding to Latin9
implicitly?
> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org=20
> [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Benjamin=20
> Krajmalnik
> Sent: Wednesday, January 16, 2008 3:45 PM
> To: Ivo Rossacher; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Strange client encoding issue
>=20
> Ivo, thank you for responding.
> I know what the error message is saying.
> The database encoding is Latin1.
> I do not know where the Latin9 encoding is coming from, since I do not
> have anywhere any settings calling for a Latin9.
> The database is accessed both by a php script on box as well as a=20
> remote ODBC connection.
> From the frequency of the requests, I am inclined to believe tht it is
> the emote connection. Unlike 8.1, 8.2 is not tagging the log message=20
> with the IP address of the client connection, so I cannot even=20
> ascertain the source of the error :(
>=20
>
>=20
> > -----Original Message-----
> > From: pgsql-admin-owner@postgresql.org=20
> > [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Ivo Rossacher
> > Sent: Wednesday, January 16, 2008 3:32 PM
> > To: pgsql-admin@postgresql.org
> > Subject: Re: [ADMIN] Strange client encoding issue
> >=20
> > The encoding of the client can not be convertet to the
> encoding of the
> > server.
> > In the manual in chapter 21.2 you can find the list of supported=20
> > encodings and possible conversions between them.
> > The conversion between latin1 and latin9 is not supported.
> > For a latin9 database you can use the client encoding
> latin9 or utf8
> > but not latin1.
> >=20
> > Best regards
> > Ivo
> >=20
> > Am Mittwoch, 16. Januar 2008 21.30:42 schrieb Benjamin Krajmalnik:
> > > I am encountering a very strange client encoding issue.
> > > From the logs on the server, I am getting the following:
> > >
> > > canopy02# tail postgresql-2008-01-16_000000.log
> > > 2008-01-16 15:20:03 ESTERROR: conversion between latin9
> > and LATIN1 is
> > > not supported
> > > 2008-01-16 15:20:03 ESTSTATEMENT: set client_encoding to 'latin9'
> > > 2008-01-16 15:20:06 ESTLOG: connection received:=20
> > host=3D192.168.111.25
> > > port=3D4236
> > > 2008-01-16 15:20:06 ESTLOG: connection authorized: user=3Dpostgres=
=20
> > > database=3Dishield
> > > 2008-01-16 15:20:06 ESTERROR: conversion between latin9
> > and LATIN1 is
> > > not supported
> > > 2008-01-16 15:20:06 ESTSTATEMENT: set client_encoding to 'latin9'
> > > 2008-01-16 15:20:11 ESTLOG: connection received:=20
> > host=3D192.168.111.25
> > > port=3D4253
> > > 2008-01-16 15:20:11 ESTLOG: connection authorized: user=3Dpostgres=
=20
> > > database=3Dishield
> > > 2008-01-16 15:20:11 ESTERROR: conversion between latin9
> > and LATIN1 is
> > > not supported
> > > 2008-01-16 15:20:11 ESTSTATEMENT: set client_encoding to 'latin9'
> > >
> > > The application logging data is using the PostgreSQL ANSI
> > ODBC driver,
> > > version 08.01.02.00.
> > > Database server is PostgreSQL 8.2.5 on i386-portbld-freebsd6.2,=20
> > > compiled by GCC cc (GCC) 3.4.6 [FreeBSD] 20060305
> > >
> > > On page 2 of the datasources tab, in the Connect Settings
> > tab, I have
> > > the following:
> > >
> > > set client_encoding to 'latin1';
> > >
> > > to force the encoding.
> > > Any ideas on what may be creating this, and how to resolve it?
> >=20
> >=20
> >=20
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >=20
> > http://www.postgresql.org/docs/faq
> >=20
>=20
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>=20
> http://www.postgresql.org/docs/faq
>=20
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: FW: [ADMIN] Strange client encoding issue
am 17.01.2008 19:16:55 von Hiroshi Saito
Hi.
Sorry, very late reaction...
It is strange.?_?
please send me mylog output of psqlODBC.
Regards,
Hiroshi Saito
----- Original Message -----
From: "Benjamin Krajmalnik"
To:
Sent: Friday, January 18, 2008 2:49 AM
Subject: [ODBC] FW: [ADMIN] Strange client encoding issue
I posted this info in ADMIN.
Any insight from the ODBC core team will be appreciated.
Thi is not causing problems in the actual data, since there is no Latin9
data and technically Latin9 is a superset of Latin1. I was just
wondering what can be causing the ODBC driver to issue a set
client_encoding to 'latin9' implicitly.
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Benjamin
Krajmalnik
Sent: Wednesday, January 16, 2008 10:17 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Strange client encoding issue
Additional info:
Thanks to Tom Lane, who pointed me in the right direction concerning the
logging to identify the connection creating the problem.
The error is most definitely being generated by the ODBC connection.
What can be causing the ODBC driver to set the client encoding to Latin9
implicitly?
> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org
> [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Benjamin
> Krajmalnik
> Sent: Wednesday, January 16, 2008 3:45 PM
> To: Ivo Rossacher; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Strange client encoding issue
>
> Ivo, thank you for responding.
> I know what the error message is saying.
> The database encoding is Latin1.
> I do not know where the Latin9 encoding is coming from, since I do not
> have anywhere any settings calling for a Latin9.
> The database is accessed both by a php script on box as well as a
> remote ODBC connection.
> From the frequency of the requests, I am inclined to believe tht it is
> the emote connection. Unlike 8.1, 8.2 is not tagging the log message
> with the IP address of the client connection, so I cannot even
> ascertain the source of the error :(
>
>
>
> > -----Original Message-----
> > From: pgsql-admin-owner@postgresql.org
> > [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Ivo Rossacher
> > Sent: Wednesday, January 16, 2008 3:32 PM
> > To: pgsql-admin@postgresql.org
> > Subject: Re: [ADMIN] Strange client encoding issue
> >
> > The encoding of the client can not be convertet to the
> encoding of the
> > server.
> > In the manual in chapter 21.2 you can find the list of supported
> > encodings and possible conversions between them.
> > The conversion between latin1 and latin9 is not supported.
> > For a latin9 database you can use the client encoding
> latin9 or utf8
> > but not latin1.
> >
> > Best regards
> > Ivo
> >
> > Am Mittwoch, 16. Januar 2008 21.30:42 schrieb Benjamin Krajmalnik:
> > > I am encountering a very strange client encoding issue.
> > > From the logs on the server, I am getting the following:
> > >
> > > canopy02# tail postgresql-2008-01-16_000000.log
> > > 2008-01-16 15:20:03 ESTERROR: conversion between latin9
> > and LATIN1 is
> > > not supported
> > > 2008-01-16 15:20:03 ESTSTATEMENT: set client_encoding to 'latin9'
> > > 2008-01-16 15:20:06 ESTLOG: connection received:
> > host=192.168.111.25
> > > port=4236
> > > 2008-01-16 15:20:06 ESTLOG: connection authorized: user=postgres
> > > database=ishield
> > > 2008-01-16 15:20:06 ESTERROR: conversion between latin9
> > and LATIN1 is
> > > not supported
> > > 2008-01-16 15:20:06 ESTSTATEMENT: set client_encoding to 'latin9'
> > > 2008-01-16 15:20:11 ESTLOG: connection received:
> > host=192.168.111.25
> > > port=4253
> > > 2008-01-16 15:20:11 ESTLOG: connection authorized: user=postgres
> > > database=ishield
> > > 2008-01-16 15:20:11 ESTERROR: conversion between latin9
> > and LATIN1 is
> > > not supported
> > > 2008-01-16 15:20:11 ESTSTATEMENT: set client_encoding to 'latin9'
> > >
> > > The application logging data is using the PostgreSQL ANSI
> > ODBC driver,
> > > version 08.01.02.00.
> > > Database server is PostgreSQL 8.2.5 on i386-portbld-freebsd6.2,
> > > compiled by GCC cc (GCC) 3.4.6 [FreeBSD] 20060305
> > >
> > > On page 2 of the datasources tab, in the Connect Settings
> > tab, I have
> > > the following:
> > >
> > > set client_encoding to 'latin1';
> > >
> > > to force the encoding.
> > > Any ideas on what may be creating this, and how to resolve it?
> >
> >
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/docs/faq
> >
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly