Postgres Pro
Downloads
Home   >   mailing lists

Thread: BUG #4196: Backend crash possible with psql

BUG #4196: Backend crash possible with psql

From
"Daniel Mihowski"
Date:
The following bug has been logged online:

Bug reference:      4196
Logged by:          Daniel Mihowski
Email address:      dmigowski@ikoffice.de
PostgreSQL version: 8.3.1
Operating system:   Windows XP
Description:        Backend crash possible with psql
Details:

Hello, dear developers. When accessing the local postgresql server with
PGAdmin, it closes abnormally. This is my psql window:

#####################################################
Passwort f³r Benutzer postgres:
Dies ist psql 8.3.1, das interaktive PostgreSQL-Terminal.

Geben Sie ein:  \copyright für Urheberrechtsinformationen
                \h für Hilfe über SQL-Anweisungen
                \? für Hilfe über interne Anweisungen
                \g oder Semikolon, um eine Anfrage auszuführen
                \q um zu beenden

Warnung: Konsolencodeseite (850) unterscheidet sich von der Windows-
         Codeseite (1252). 8-Bit-Zeichen funktionieren möglicherweise
nicht
         richtig. Einzelheiten finden Sie auf der psql-Handbuchseite unter
         »Notes for Windows users«.

postgres=# \set
AUTOCOMMIT = 'on'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
VERBOSITY = 'default'
VERSION = 'PostgreSQL 8.3.1, compiled by Visual C++ build 1400'
DBNAME = 'postgres'
USER = 'postgres'
HOST = 'localhost'
PORT = '5434'
ENCODING = 'WIN1252'
postgres=# select blah;
#####################################################

After entering the last line, the postgres.exe process crashes. These are
the last lines of the logfile:

#####################################################
2008-05-26 10:29:20 CEST LOG:  Anweisung: select blah;
2008-05-26 10:29:20 CEST FEHLER:  Spalte »blah« existiert nicht bei
Zeichen 8
2008-05-26 10:29:20 CEST ANWEISUNG:  select blah;
2008-05-26 10:29:20 CEST FEHLER:  ungültige Byte-Sequenz für Kodierung
»UTF8«: 0xbb
2008-05-26 10:29:20 CEST TIPP:  Dieser Fehler kann auch auftreten, wenn die
Bytesequenz nicht mit der Kodierung übereinstimmt, die der Server erwartet,
welche durch »client_encoding« bestimmt wird.
2008-05-26 10:29:20 CEST ANWEISUNG:  select blah;
2008-05-26 10:29:20 CEST FEHLER:  ungültige Byte-Sequenz für Kodierung
»UTF8«: 0xfc
2008-05-26 10:29:20 CEST TIPP:  Dieser Fehler kann auch auftreten, wenn die
Bytesequenz nicht mit der Kodierung übereinstimmt, die der Server erwartet,
welche durch »client_encoding« bestimmt wird.
2008-05-26 10:29:20 CEST FEHLER:  ungültige Byte-Sequenz für Kodierung
»UTF8«: 0xfc
2008-05-26 10:29:20 CEST TIPP:  Dieser Fehler kann auch auftreten, wenn die
Bytesequenz nicht mit der Kodierung übereinstimmt, die der Server erwartet,
welche durch »client_encoding« bestimmt wird.
2008-05-26 10:29:20 CEST FEHLER:  ungültige Byte-Sequenz für Kodierung
»UTF8«: 0xfc
2008-05-26 10:29:20 CEST TIPP:  Dieser Fehler kann auch auftreten, wenn die
Bytesequenz nicht mit der Kodierung übereinstimmt, die der Server erwartet,
welche durch »client_encoding« bestimmt wird.
2008-05-26 10:29:20 CEST PANIK:  ERRORDATA_STACK_SIZE exceeded


This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
#####################################################

Since it looks like some encoding problem, the following information might
be heldful, too: My windows version is a German one, and the backend was
initialized with a german locale, sort order, etc.

With best regards,
Daniel Migowski

Re: BUG #4196: Backend crash possible with psql

From
Tom Lane
Date:
"Daniel Mihowski" <dmigowski@ikoffice.de> writes:
> Description:        Backend crash possible with psql

We've seen several similar reports, but the conditions that cause it are
not clear.  Please show the values you are using for these database
parameters:
    client_encoding
    server_encoding
    lc_collate
    lc_ctype
    lc_messages

            regards, tom lane

Re: BUG #4196: Backend crash possible with psql

From
Daniel Migowski
Date:
Hello Tom,

Tom Lane schrieb:
> Please show the values you are using for these database
> parameters:
>     client_encoding
>     server_encoding
>     lc_collate
>     lc_ctype
>     lc_messages
client_encoding: WIN1252
server_encoding: UTF8
lc_collate:      German_Germany.1252
lc_ctype:        German_Germany.1252
lc_messages:     German_Germany

Please let me know if you need more info. For me it looks like the
server reads the localized error messages in system encoding (win1252),
but assumes they are in utf8 in the server.

With best regards,
Daniel Migowski

Re: BUG #4196: Backend crash possible with psql

From
Tom Lane
Date:
Daniel Migowski <dmigowski@ikoffice.de> writes:
> client_encoding: WIN1252
> server_encoding: UTF8
> lc_collate:      German_Germany.1252
> lc_ctype:        German_Germany.1252
> lc_messages:     German_Germany

Thanks for the info --- we have been unable to get these values from
previous complainants, so this is a real help.

> Please let me know if you need more info. For me it looks like the
> server reads the localized error messages in system encoding (win1252),
> but assumes they are in utf8 in the server.

Yeah, that's what I think too.  Specifically, we expect the gettext
package to deliver translated error messages in the server_encoding,
but it seems that's not what we're getting on Windows.  Without having
dug into the gettext code, I wonder whether it is looking at lc_ctype
and thinking it should return WIN1252 strings.

Another interesting question is how initdb allowed you to select the
above combination of settings.  8.3 is supposed to enforce that
server_encoding is the same as the encoding implied by lc_ctype,
which is evidently not the case here.  I recall we were tinkering with
that code before 8.3 release, but I guess it's still not right :-(

            regards, tom lane

Re: BUG #4196: Backend crash possible with psql

From
Tom Lane
Date:
Oh, one other thing: if the theory about gettext delivering the "wrong"
encoding is correct, then the error messages going into the postmaster
log should be in WIN1252 encoding, rather than UTF8 which is the
intended behavior when server_encoding is UTF8.  The log snippet in your
bug report was UTF8, but that might have gotten converted somewhere
along the line.  Can you confirm which encoding is actually present in
the log file?

            regards, tom lane

Re: BUG #4196: Backend crash possible with psql

From
Daniel Migowski
Date:
Hello, Tom,

Tom Lane schrieb:
>
> Yeah, that's what I think too.  Specifically, we expect the gettext
> package to deliver translated error messages in the server_encoding,
> but it seems that's not what we're getting on Windows.  Without having
> dug into the gettext code, I wonder whether it is looking at lc_ctype
> and thinking it should return WIN1252 strings.
>
> Another interesting question is how initdb allowed you to select the
> above combination of settings.  8.3 is supposed to enforce that
> server_encoding is the same as the encoding implied by lc_ctype,
> which is evidently not the case here.
Why shouldn't this be possible? It must be possible to store the data in
UTF-8, and of course, to use this a the server encoding. The characters
used should be collated by German and use the german upper/lower
conventions. Looks perfectly sane to me.
> I recall we were tinkering with
> that code before 8.3 release, but I guess it's still not right :-(
>
>             regards, tom lane
>
With best regards,
Daniel Migowski

Re: BUG #4196: Backend crash possible with psql

From
Tom Lane
Date:
"Daniel Mihowski" <dmigowski@ikoffice.de> writes:
> Bug reference:      4196
> Logged by:          Daniel Mihowski
> Email address:      dmigowski@ikoffice.de
> PostgreSQL version: 8.3.1
> Operating system:   Windows XP
> Description:        Backend crash possible with psql
> Details:

> Hello, dear developers. When accessing the local postgresql server with
> PGAdmin, it closes abnormally. This is my psql window:

This is now believed fixed, and will be in 8.3.2:
http://archives.postgresql.org/pgsql-committers/2008-05/msg00349.php

Thanks for your help in isolating the cause.

            regards, tom lane