Thread: ERRORDATA_STACK_SIZE exceeded
Hello,
I've got a failing sql-Script that I execute with the psql command. The
Script contains:
----------------------------8<-----------------------------
SET CLIENT_ENCODING = 'LATIN1';
(Some other statements)
CREATE TABLE "public"."init_camera_type" (
"id_camera_type" SMALLINT NOT NULL,
"name" VARCHAR(75) NOT NULL,
"is_video_camera" BOOLEAN DEFAULT false NOT NULL,
"description" VARCHAR(75),
PRIMARY KEY("id_camera_type")
) WITH OIDS;
----------------------------8<-----------------------------
where it bails out. The console output is:
----------------------------8<-----------------------------
PANIK: ERRORDATA_STACK_SIZE exceeded
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
----------------------------8<-----------------------------
The postgresql.log writes:
----------------------------8<-----------------------------
2006-10-17 13:04:03 CEST FEHLER: 22021: ungültige Byte-Sequenz für
Kodierung »UTF8«: 0xbb
2006-10-17 13:04:03 CEST ORT: report_invalid_encoding, wchar.c:1328
2006-10-17 13:04:03 CEST ANWEISUNG: CREATE TABLE
"public"."init_camera_type" (
"id_camera_type" SMALLINT NOT NULL,
"name" VARCHAR(75) NOT NULL,
"is_video_camera" BOOLEAN DEFAULT false NOT NULL,
"description" VARCHAR(75),
PRIMARY KEY("id_camera_type")
) WITH OIDS;
2006-10-17 13:04:03 CEST FEHLER: 22021: ungültige Byte-Sequenz für
Kodierung »UTF8«: 0xfc6c74696765
2006-10-17 13:04:03 CEST ORT: report_invalid_encoding, wchar.c:1328
2006-10-17 13:04:03 CEST ANWEISUNG: CREATE TABLE
"public"."init_camera_type" (
"id_camera_type" SMALLINT NOT NULL,
"name" VARCHAR(75) NOT NULL,
"is_video_camera" BOOLEAN DEFAULT false NOT NULL,
"description" VARCHAR(75),
PRIMARY KEY("id_camera_type")
) WITH OIDS;
2006-10-17 13:04:03 CEST FEHLER: 22021: ungültige Byte-Sequenz für
Kodierung »UTF8«: 0xfc6c74696765
2006-10-17 13:04:03 CEST ORT: report_invalid_encoding, wchar.c:1328
2006-10-17 13:04:03 CEST ANWEISUNG: CREATE TABLE
"public"."init_camera_type" (
"id_camera_type" SMALLINT NOT NULL,
"name" VARCHAR(75) NOT NULL,
"is_video_camera" BOOLEAN DEFAULT false NOT NULL,
"description" VARCHAR(75),
PRIMARY KEY("id_camera_type")
) WITH OIDS;
2006-10-17 13:04:03 CEST FEHLER: 22021: ungültige Byte-Sequenz für
Kodierung »UTF8«: 0xfc6c74696765
2006-10-17 13:04:03 CEST ORT: report_invalid_encoding, wchar.c:1328
2006-10-17 13:04:03 CEST ANWEISUNG: CREATE TABLE
"public"."init_camera_type" (
"id_camera_type" SMALLINT NOT NULL,
"name" VARCHAR(75) NOT NULL,
"is_video_camera" BOOLEAN DEFAULT false NOT NULL,
"description" VARCHAR(75),
PRIMARY KEY("id_camera_type")
) WITH OIDS;
2006-10-17 13:04:03 CEST PANIK: XX000: ERRORDATA_STACK_SIZE exceeded
2006-10-17 13:04:03 CEST ORT: errstart, elog.c:274
2006-10-17 13:04:03 CEST ANWEISUNG: CREATE TABLE
"public"."init_camera_type" (
"id_camera_type" SMALLINT NOT NULL,
"name" VARCHAR(75) NOT NULL,
"is_video_camera" BOOLEAN DEFAULT false NOT NULL,
"description" VARCHAR(75),
PRIMARY KEY("id_camera_type")
) WITH OIDS;
2006-10-17 13:04:03 CEST DEBUG: 00000: reaping dead processes
2006-10-17 13:04:03 CEST ORT: reaper, postmaster.c:2021
2006-10-17 13:04:03 CEST DEBUG: 00000: Serverprozess (PID 32435) wurde
von Signal 6 beendet
2006-10-17 13:04:03 CEST ORT: LogChildExit, postmaster.c:2428
----------------------------8<-----------------------------
I don't think there are invalid byte sequences in my script. In fact
there is no occurrence of 0xbb anywhere in the script.
The database that script is applied to is UTF8 encoded.
The postgresql version is 8.1.4.
My system is Linux pc01 2.6.17-gentoo-r8 #2 SMP Mon Oct 16 11:23:12 CEST
2006 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz GNU/Linux
Is there someone who can explain what's going on here?
Regards
Stefan
Hallo Stefan, Stefan Sassenberg wrote: > Hello, > > I've got a failing sql-Script that I execute with the psql command. The > Script contains: I've been unable to reproduce the error with just that snippet (on debian with PostgreSQL 8.1.4). Can you provide a stripped down test case? > ----------------------------8<----------------------------- > PANIK: ERRORDATA_STACK_SIZE exceeded > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > ----------------------------8<----------------------------- 'Exceeding stack size' sound somewhat like an infinite loop of a recursive function... but that's just a very general guess. I think the root cause of problems is somewhere else. Regards Markus
Hallo Markus, Markus Schiltknecht wrote: > Hallo Stefan, > > Stefan Sassenberg wrote: >> Hello, >> >> I've got a failing sql-Script that I execute with the psql command. >> The Script contains: > > I've been unable to reproduce the error with just that snippet (on > debian with PostgreSQL 8.1.4). Can you provide a stripped down test case? Reproduction is difficult. The script runs fine with the same db on another server with a Linux derived from Knoppix, but also postgresql 8.1.4. > >> ----------------------------8<----------------------------- >> PANIK: ERRORDATA_STACK_SIZE exceeded >> server closed the connection unexpectedly >> This probably means the server terminated abnormally >> before or while processing the request. >> ----------------------------8<----------------------------- > > 'Exceeding stack size' sound somewhat like an infinite loop of a > recursive function... but that's just a very general guess. I think the > root cause of problems is somewhere else. As I see it, ERRORDATA_STACK_SIZE is a constant that is defined in the code (pgsql/src/backend/utils/error/elog.c) as 5. 5 illegal bytecodes that postgresql finds in my statement are enough to cause the panic. Stefan
Stefan Sassenberg wrote: > Hello, > > I've got a failing sql-Script that I execute with the psql command. The > Script contains: > > ----------------------------8<----------------------------- > SET CLIENT_ENCODING = 'LATIN1'; <snip> > The database that script is applied to is UTF8 encoded. Stefan Sassenberg wrote: > As I see it, ERRORDATA_STACK_SIZE is a constant that is defined in the > code (pgsql/src/backend/utils/error/elog.c) as 5. 5 illegal bytecodes > that postgresql finds in my statement are enough to cause the panic. Could the difference between CLIENT_ENCODING = 'LATIN1' and database_encoding = UTF8 create the illegal bytecodes? I just found a way to get a similar error - create db with utf8 encoding save file with the create table command - save as unicode-utf16 I then get - %>psql enctest < test ERROR: invalid byte sequence for encoding "UTF8": 0xfe HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". If I save the file as latin1 or utf8 I have no problems. I would be looking for the error somewhere in the (some other statements) part and would expect an invisible/unprintable char of some sort. > SET CLIENT_ENCODING = 'LATIN1'; > > (Some other statements) > > CREATE TABLE -- Shane Ambler Postgres@007Marketing.com Get Sheeky @ http://Sheeky.Biz
Hello Shane, Shane Ambler wrote: > Stefan Sassenberg wrote: >> Hello, >> >> I've got a failing sql-Script that I execute with the psql command. >> The Script contains: >> >> ----------------------------8<----------------------------- >> SET CLIENT_ENCODING = 'LATIN1'; > > <snip> > >> The database that script is applied to is UTF8 encoded. > > Stefan Sassenberg wrote: > > As I see it, ERRORDATA_STACK_SIZE is a constant that is defined in the > > code (pgsql/src/backend/utils/error/elog.c) as 5. 5 illegal bytecodes > > that postgresql finds in my statement are enough to cause the panic. > > > Could the difference between CLIENT_ENCODING = 'LATIN1' and > database_encoding = UTF8 create the illegal bytecodes? > > > I just found a way to get a similar error - > create db with utf8 encoding > save file with the create table command - save as unicode-utf16 > > I then get - > %>psql enctest < test > ERROR: invalid byte sequence for encoding "UTF8": 0xfe In my case, the illegal byte code is 0xbb. I used hexdump|grep to find occurrences of "bb" in my file script file but there isn't any. I'm using that way of writing and encoding scripts for years. Nothing seems to have changed. Stefan
Stefan Sassenberg <stefan.sassenberg@gmx.de> writes:
> PANIK: ERRORDATA_STACK_SIZE exceeded
> server closed the connection unexpectedly
What LC_CTYPE and LC_MESSAGES settings are you using? We've seen
problems of this ilk when gettext() produces messages encoded in the
"wrong" encoding (ie, not what the database encoding is).
regards, tom lane
Hello Tom, Tom Lane wrote: > Stefan Sassenberg <stefan.sassenberg@gmx.de> writes: >> PANIK: ERRORDATA_STACK_SIZE exceeded >> server closed the connection unexpectedly > > What LC_CTYPE and LC_MESSAGES settings are you using? We've seen > problems of this ilk when gettext() produces messages encoded in the > "wrong" encoding (ie, not what the database encoding is). postgresql.conf has an entry lc_messages = 'de_DE@euro' postgresql.log says [...] LC_MESSAGES=de_DE@euro I can't find anything about LC_CTYPE. No user on my machine has any of those variables as environment variables. Update: I copied the script text into a pgadmin query window and found out, that the error vanishes when I comment out all CONSTRAINT lines from my CREATE TABLE statements. Stefan
Stefan Sassenberg <stefan.sassenberg@gmx.de> writes:
> Tom Lane wrote:
>> What LC_CTYPE and LC_MESSAGES settings are you using? We've seen
>> problems of this ilk when gettext() produces messages encoded in the
>> "wrong" encoding (ie, not what the database encoding is).
> postgresql.log says [...] LC_MESSAGES=de_DE@euro
Hm. You'll need to check your platform's locale settings, but I bet
that that setting implies LATIN1 encoding (or LATINsomething anyway).
So any message text that gettext produces that happens to contain
high-bit-set LATIN characters would be invalidly encoded in a UTF8
database. The particular case that causes error stack overflow is
where the message about invalid conversion itself has the problem :-(
The real bottom line here is that your locale settings have to imply
an encoding that is the same as the database encoding. This is just
one of the things that can go wrong when they're different.
> I can't find anything about LC_CTYPE.
"show lc_type" would tell you, but it's probably the same.
regards, tom lane
Tom Lane wrote: > Stefan Sassenberg <stefan.sassenberg@gmx.de> writes: >> Tom Lane wrote: >>> What LC_CTYPE and LC_MESSAGES settings are you using? We've seen >>> problems of this ilk when gettext() produces messages encoded in the >>> "wrong" encoding (ie, not what the database encoding is). > >> postgresql.log says [...] LC_MESSAGES=de_DE@euro > > Hm. You'll need to check your platform's locale settings, but I bet > that that setting implies LATIN1 encoding (or LATINsomething anyway). > So any message text that gettext produces that happens to contain > high-bit-set LATIN characters would be invalidly encoded in a UTF8 > database. The particular case that causes error stack overflow is > where the message about invalid conversion itself has the problem :-( > > The real bottom line here is that your locale settings have to imply > an encoding that is the same as the database encoding. This is just > one of the things that can go wrong when they're different. > >> I can't find anything about LC_CTYPE. > > "show lc_type" would tell you, but it's probably the same. de_DE@euro is ISO-8859-15, if that helps. I changed the locale to en_US.UTF-8 and LC_CTYPE in the environment is set to that value too. Nevertheless "show lc_ctype" says de_DE@euro, even after a postgresql restart. How can I change that? Stefan
Stefan Sassenberg <stefan.sassenberg@gmx.de> writes:
> de_DE@euro is ISO-8859-15, if that helps. I changed the locale to
> en_US.UTF-8 and LC_CTYPE in the environment is set to that value too.
> Nevertheless "show lc_ctype" says de_DE@euro, even after a postgresql
> restart. How can I change that?
initdb is the only way to change the database's LC_CTYPE or LC_COLLATE :-(
regards, tom lane
Tom Lane wrote: > Stefan Sassenberg <stefan.sassenberg@gmx.de> writes: >> de_DE@euro is ISO-8859-15, if that helps. I changed the locale to >> en_US.UTF-8 and LC_CTYPE in the environment is set to that value too. >> Nevertheless "show lc_ctype" says de_DE@euro, even after a postgresql >> restart. How can I change that? > > initdb is the only way to change the database's LC_CTYPE or LC_COLLATE :-( That's ok for now, I can do so [type type type]. Done. Fine, now my script runs perfectly. Thanks to all who answered. In the initdb man pages I saw that I can set locale variables, so there's no need to switch my entire environment to a locale that I don't want. Is it a necessary restriction that the db encoding must match the lc_ctype? I can remember a case when I had two dbs with different encodings and this might happen again. Or is it a problem that I'm using a localized version of postgresql that uses special characters in the messages? Stefan
Stefan Sassenberg <stefan.sassenberg@gmx.de> writes:
> Is it a necessary restriction that the db encoding must match the
> lc_ctype?
If you set the LC_ variables to "C" you can get away with using
different encodings, but I wouldn't recommend it for any other locale
setting. Aside from the message translation issue, there are unpleasant
side effects for sorting and upper/lower case conversion.
regards, tom lane