Re: PG 9.4.4 issue on French Windows 32 bits - Mailing list pgsql-general

On 07/08/2015 08:40 AM, Thierry Hauchard wrote:
> There is NO problem on 64 bits machines with PG 64 bits.

I saw this line from your previous post:

"No issue on 64bits machine (majority of our customers)."

Realize now that this means the majority of your customers are using
64bit Windows. I read it as there was no problem on the majority of the
machines that ran 64bit, which implied there where some 64bit machines
that has issues. Looking from wrong end of telescope:)

> (We have not try PG 32 bits on 64 bits machine.)
> There IS problem on all 32 bits machine with PG 32 bits
>
> All databases are encoded on PG in UTF8

Just to be clear the 8.4 versions of the database where set up with UTF8?

>
> We set that on all connexions :
> SET CLIENT_ENCODING TO WIN1252;
> SET bytea_output TO escape;
> SET standard_conforming_strings TO false;

What library are you using to make connections in your application?

>
> I don't use psql. So i don't anderstand when i must type  "\encoding
> win1252".
> if i use psql on the test 9.4.4 database and type "\encoding win1252",
> nothing happens

Actually something does happen:

postgres@production=# \encoding
UTF8
postgres@production=# \encoding win_1252
postgres@production=# \encoding
WIN1252

For more detail see here:
http://www.postgresql.org/docs/9.4/interactive/app-psql.html

> If then i try a simple query updating string with "\\", value is stored
> If i do same thing with some accentuated char : "\\éà", there are NOT
> updated in database, and no error (and nothing in PG log)

Can you show the actual full queries and return values or errors from in
psql command line?


> If i do that from PG_Admin, it works
> If i type "SET CLIENT_ENCODING TO WIN1252;", psql return error : invalid
> byte sequence for encoding "UTF8": 0xe9 0x71 0x75

The psql in the above confuses me. Are you referring to the command line
program psql or to the Postgres server?

Generally psql is used to refer to the command line program and Postgres
or Pg(pg) is used to refer to the server.

> If i do that from PG_Admin, it works
> If i type "SET CLIENT_ENCODING TO WIN1252"  (without ";"), it works

I do not use pgAdmin enough, but I am guessing it adds the ; when it
parses the command.

>
> I don't see any coherent things !  :(
>
> Thanks,
> --
> Thierry
> Gesteam
>
> Le 08/07/2015 15:20, Adrian Klaver a écrit :
>> On 07/08/2015 01:04 AM, Thierry Hauchard wrote:
>>> Hy,
>>>
>>> We can't upgrade our customers from 8.4 to 9.4.4 if they have a 32 bits
>>> server machine (Windows 2008, 2007...).
>>> There is no problem with PG 64 bits.
>>
>> Except below you say only for majority of 64bit machines, so are the
>> problems when they occur the same as you are seeing on the 32bit
>> machines?
>>
>>>
>>> When restoring from backup (created from 8.4 database with PG_Dump
>>> 9.4.4), the log shows errors about UTF like :
>>> 2015-07-07 17:03:35 CEST ERREUR:  séquence d'octets invalide pour
>>> l'encodage « UTF8 » : 0xf4 0x6c 0x65 0x20
>>
>> So what is the database encoding in the 8.4 instances?
>>
>>>
>>> Using our application, using win_1252 client_encoding,  get similar
>>> error if we try to update record with a "\" in any string :
>>
>> So what happens if you use psql and do:
>>
>> \encoding win_1252
>>
>> and then run the query below?
>>
>>>
>>> UPDATE test_table SET str_field = '\\' WHERE id = 75160909
>>> -> ERROR:  invalid byte sequence for encoding "UTF8": 0xee 0x6e 0x65
>>>
>>> The same query work from PG_Admin (UTF8 encoding)
>>
>> Make me think you had database in an encoding other then UTF8 previously.
>>
>>>
>>> Our technicien install PG cluster exactly the same way.
>>> We have tried on 3 differents 32 bits machine, same issue
>>> No issue on 64bits machine (majority of our customers). All works
>>> perfectly.
>>> We have never had any problem with PG 8.4 for long years
>>>
>>> Is there a way to turn-over ?
>>> Or need to wait upgrade ?
>>>
>>> Thanks,
>>> Thierry Hauchard
>>> Gesteam
>>>
>>>
>>
>>
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com