WG: [GENERAL] reproducible database crash with simple sql command on postgres 8.3.1 - Mailing list pgsql-bugs

ok
=20
regards christian
=20
=20
________________________________

Please forward this info to pgsql-bugs.  I don't have a Windows machine
so I can't look into it myself.

                        regards, tom lane




________________________________

Von: Strobl, Christian
Gesendet: Fr 16.05.2008 17:42
An: Tom Lane
Betreff: AW: [GENERAL] reproducible database crash with simple sql command =
on postgres 8.3.1=20


=20
hi tom,
=20
please excuse my delayed answer, but i wasn't in the office and i undertook=
 some additional testing
=20
1) postgres=3D# show lc_messages;
      lc_messages
-----------------------
 English_United States
(1 Zeile)

formerly it was German_Germany. but also if i change to English_United Stat=
es with=20
=20
set lc_messages =3D 'English_United States'
=20
there is no change in the language of the messages, also after a complete d=
einstallation-installation-process with english as default the language in =
the shell (dosbox and powershell) is still german. for me this seems very s=
trange.
=20
2) postgres=3D# show lc_ctype;
          lc_ctype
----------------------------
 English_United States.1252
(1 Zeile)
=20
3) postgres=3D# show server_encoding;
 server_encoding
-----------------
 UTF8
(1 Zeile)
=20
4a) postgres=3D# show client_encoding;
 client_encoding
-----------------
 win1252
(1 Zeile)
=20
now to the really strange behaviour: with win 1252 (or latin 1) i can use g=
erman special characters for example in insert-statements (i changed  in th=
e shell also the codepage to windows 1252 with chcp 1252)
=20
create table test (name varchar);
insert into test (name) values ('=E4=F6=FC');
select * from test;

name
------
 abc
 =E4=F6=FC
 =E4=F6=FC
(3 Zeilen)
=20
as far as good. but if i make some mistake with psql for example=20
=20
x;
=20
i get the follwing message
=20
postgres=3D# x;
PANIK:  ERRORDATA_STACK_SIZE exceeded
Server beendete die Verbindung unerwartet
        Das hei=DFt wahrscheinlich, da=DF der Server abnormal beendete
        bevor oder w=E4hrend die Anweisung bearbeitet wurde.
Die Verbindung zum Server wurde verloren.  Versuche Reset: Fehlgeschlagen.
=20
the worst is that also the is now down and has to be restarted
=20
=20
4b) postgres=3D# show client_encoding;
 client_encoding
-----------------
 UTF8
(1 Zeile)
=20
now its not possible to insert german special characters with sql-statements
=20
the follwing statement=20
=20
insert into test (name) values ('=E4=F6=FC');
=20
gives the follwing error message
=20
postgres=3D# insert into test (name) values ('=E4=F6=FC');
FEHLER:  ung=FCltige Byte-Sequenz f=FCr Kodierung =BBUTF8=AB: 0xe4f6fc
TIP:  Dieser Fehler kann auch auftreten, wenn die Bytesequenz nicht mit der=
 Kodierung =FCbereinstimmt, die der Server
erwartet, welche durch =BBclient_encoding=AB bestimmt wird.
=20
but wrong statements are correctly processed  by psql
=20
postgres=3D# x;
FEHLER:  Syntaxfehler bei =BBx=AB
ZEILE 1: x;
=20
thats the things i collected with this problem
=20
thanks and greetings from munich
christian
=20
p.s. i don't know if you can see the german special characters at your emai=
l client. these are the letters for ae, oe and ue
p.p.s. without a exact explanation my impression is that the wole thing is =
working better with pgadmin III but also not without some problems
p.p.p.s if you are interested i can also send you some log-files but for ex=
ample the install log file is quite large (> 4MB)
=20
=20
=20
=20
=20=20
=20

=20
________________________________

Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Gesendet: Fr 09.05.2008 16:18
An: Strobl, Christian
Cc: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] reproducible database crash with simple sql command =
on postgres 8.3.1=20



<Christian.Strobl@dlr.de> writes:
> PANIK: ERROR_STACK_SIZE exceeded

> the rest of the message is unfortunately in german then i have to
> restart the postgres-service manually this error is very easy
> reproducible at my environment

What this typically means is that you've got an encoding/locale
configuration problem.  The thing is trying to report some error
or other, and it discovers that the error text is badly encoded
according to the current database encoding, and it tries to
report that, only *that* error text is badly encoded too, so
it tries to report that, getting another error, etc, until the
error recovery stack overflows.

The hope of getting rid of this scenario is one reason why we locked
down encoding/locale combinations in 8.3, so I'm disappointed that
you're still able to make it happen.  You didn't say what settings
you are using though.  Could we see

        show lc_messages;
        show lc_ctype;
        show server_encoding;
        show client_encoding;

                        regards, tom lane