PANIC: ERRORDATA_STACK_SIZE exceeded

Hola a todos,

Intentando hacer un copy con formato csv en psql aparece el siguiente error:

PANIC: ERRORDATA_STACK_SIZE exceeded
el servidor ha cerrado la conexión inesperadamente,
probablemente porque terminó de manera anormal
antes o durante el procesamiento de la petición.
La conexión al servidor se ha perdido. Intentando reiniciar: falló.

El servidor se reinicia finalizando *todas* las conexiones activas.

Adjunto un extracto del log de postgres.

¿Alguna idea de porque sucede?

Windows SP SP1
Postgresql 8.1.1

Nota: es posible que el mensaje llegue duplicado, en el primero el from era erróneo.
--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

Oswaldo Hernández escribió:
> Hola a todos,
>
> Intentando hacer un copy con formato csv en psql aparece el siguiente error:
>
> PANIC: ERRORDATA_STACK_SIZE exceeded
> el servidor ha cerrado la conexión inesperadamente,
> probablemente porque terminó de manera anormal
> antes o durante el procesamiento de la petición.
> La conexión al servidor se ha perdido. Intentando reiniciar: falló.

Tienes un trigger recursivo en la tabla en cuestion?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera escribió:
> Oswaldo Hernández escribió:
>
>>Hola a todos,
>>
>>Intentando hacer un copy con formato csv en psql aparece el siguiente error:
>>
>>PANIC: ERRORDATA_STACK_SIZE exceeded
>>el servidor ha cerrado la conexión inesperadamente,
>> probablemente porque terminó de manera anormal
>> antes o durante el procesamiento de la petición.
>>La conexión al servidor se ha perdido. Intentando reiniciar: falló.
>
>
> Tienes un trigger recursivo en la tabla en cuestion?

No, no tiene ningun trigger, son solamnente pruebas de importacion.

Comprobando de nuevo e intentando reproducir el error me doy cuenta de que el copy lo estoy haciendo
en base de datos postgres donde no existe la tabla. (Sorry, llevo 2 dias ajustando los parametros
para la migracion de datos y ya no carburo bien)

Aun asi, segun el log parece que sí quiere importar los datos, puesto que lee al menos una parte del
archivo y muestra warnings de codificacion antes de dar el error.

He explorado la base de datos postgres por si en alguno de los esquemas existiera una tabla con el
mismo nombre (por aquello del search_path) y no existe ninguna con ese nombre.

--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

Oswaldo Hernández escribió:
> Alvaro Herrera escribió:
> >Oswaldo Hernández escribió:
> >
> >>Hola a todos,
> >>
> >>Intentando hacer un copy con formato csv en psql aparece el siguiente
> >>error:
> >>
> >>PANIC: ERRORDATA_STACK_SIZE exceeded
> >>el servidor ha cerrado la conexión inesperadamente,
> >> probablemente porque terminó de manera anormal
> >> antes o durante el procesamiento de la petición.
> >>La conexión al servidor se ha perdido. Intentando reiniciar: falló.
> >
> >Tienes un trigger recursivo en la tabla en cuestion?
>
> No, no tiene ningun trigger, son solamnente pruebas de importacion.

Hmm, interesante, ahora que examino mas de cerca el log, la secuencia
relevante es esta:

2006-06-20 18:56:07 - postgres(2616-10997)ERROR: no existe la relación «pruebas.articulos»
2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xf36e20ab
2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xe16374
2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xe16374
2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xe16374
2006-06-20 18:56:07 - postgres(2616-10997)PANIC: ERRORDATA_STACK_SIZE exceeded
2006-06-20 18:56:07 - postgres(2616-10997)SENTENCIA: copy pruebas.articulos (referencia, descripcion, ref_proveedor, proveedor, coste, pventa) from 'c:\\temp\\exportmdb\\ficheros\\exp_articulos.txt' csv;

Primero que nada, que tienes en log_line_prefix? Ese 10997 es constante
en todo este reporte; parece ser un ID de transaccion y es una pista
importante. Es importante porque el ERROR deberia haber terminado la
transaccion, sin embargo a continuacion seguramente trata de mostrar la
linea del archivo de importacion que tiene problemas (o que se yo, algo
esta tratando de convertir a UTF-8 o de vuelta), y luego, en ese intento
de conversion, se queda sin espacio de stack, y por eso el PANIC.

Esto es reproducible supongo? Puedes pasarme por favor la siguiente
informacion:

- server_encoding
- client_encoding
- un archivo con la sentencia COPY exacta que estas usando
- un archivo con los datos CSV (se me ocurre que puedes inventar un
archivo con una linea, o quizas un archivo vacio, que cause el mismo
error, dado que el problema es que la tabla no existe)
- la version exacta de Postgres, reportada segun SELECT version();

Gracias.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera escribió:

> Hmm, interesante, ahora que examino mas de cerca el log, la secuencia
> relevante es esta:
>
>
> 2006-06-20 18:56:07 - postgres(2616-10997)ERROR: no existe la relación «pruebas.articulos»
> 2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xf36e20ab
> 2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xe16374
> 2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xe16374
> 2006-06-20 18:56:07 - postgres(2616-10997)WARNING: ignorando el carácter UTF-8 no convertible 0xe16374
> 2006-06-20 18:56:07 - postgres(2616-10997)PANIC: ERRORDATA_STACK_SIZE exceeded
> 2006-06-20 18:56:07 - postgres(2616-10997)SENTENCIA: copy pruebas.articulos (referencia, descripcion, ref_proveedor, proveedor, coste, pventa) from 'c:\\temp\\exportmdb\\ficheros\\exp_articulos.txt' csv;
>
>
> Primero que nada, que tienes en log_line_prefix? Ese 10997 es constante
> en todo este reporte; parece ser un ID de transaccion y es una pista
> importante. Es importante porque el ERROR deberia haber terminado la
> transaccion, sin embargo a continuacion seguramente trata de mostrar la
> linea del archivo de importacion que tiene problemas (o que se yo, algo
> esta tratando de convertir a UTF-8 o de vuelta), y luego, en ese intento
> de conversion, se queda sin espacio de stack, y por eso el PANIC.
>
> Esto es reproducible supongo? Puedes pasarme por favor la siguiente
> informacion:
>
> - server_encoding
> - client_encoding
> - un archivo con la sentencia COPY exacta que estas usando
> - un archivo con los datos CSV (se me ocurre que puedes inventar un
> archivo con una linea, o quizas un archivo vacio, que cause el mismo
> error, dado que el problema es que la tabla no existe)
> - la version exacta de Postgres, reportada segun SELECT version();
>

log_line_prefix = '%t - %u(%p-%x)'

postgres=# show server_encoding;
server_encoding
-----------------
UTF8
(1 fila)

postgres=# show client_encoding;
client_encoding
-----------------
UTF8
(1 fila)
* Este el el valor por defecto de client_encoding, antes del error lo modifico.

postgres=# select version();
version
------------------------------------------------------------------------------------------
PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)
(1 fila)

Reproducción del error:
-----------------------
C:\Archivos de programa\PostgreSQL\8.1\bin>psql postgres postgres
Bienvenido a psql 8.1.1, la terminal interactiva de PostgreSQL.

Digite: \copyright para ver los tÚrminos de distribuci¾n
\h para ayuda de comandos SQL
\? para ayuda de comandos psql
\g o or termine con punto y coma para ejecutar una consulta
\q para salir

Precauci¾n: El c¾digo de pßgina de la consola (850) difiere del c¾digo
de pßgina de Windows (1252).
Los caracteres de 8 bits pueden funcionar incorrectamente.
Vea la pßgina de referencia de psql ½Notes for Windows users╗
para obtener mßs detalles.
postgres=# set client_encoding to windows_1250;
SET
postgres=# copy pruebas.x from 'c:\\temp\\datoscopy.txt' csv;
PANIC: ERRORDATA_STACK_SIZE exceeded
el servidor ha cerrado la conexi¾n inesperadamente,
probablemente porque termin¾ de manera anormal
antes o durante el procesamiento de la petici¾n.
La conexi¾n al servidor se ha perdido. Intentando reiniciar: fall¾.
!>

NOTAS:
------
1.- El error se produce cuando el esquema si existe, pero la tabla no.
Si el esquema tampoco existe:

postgres=# copy x.x from 'c:\\temp\\datoscopy.txt' csv;
ERROR: no existe el esquema «x»

2.- Si cambio de base de datos y vuelvo a la base de datos en la que no existe la tabla, *ya no se
produce el error* :

Bienvenido a psql 8.1.1, la terminal interactiva de PostgreSQL.

Digite: \copyright para ver los términos de distribución
\h para ayuda de comandos SQL
\? para ayuda de comandos psql
\g o or termine con punto y coma para ejecutar una consulta
\q para salir

postgres=# \c otra
Ahora está conectado a la base de datos «otra».
soft-com=# \c postgres
Ahora está conectado a la base de datos «postgres».
postgres=# copy pruebas.x from 'c:\\temp\\datoscopy.txt' csv;
ERROR: no existe la relación «pruebas.x»

No se si olvido enviar algo.

Saludos,

--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

Oswaldo Hernández escribió:

> Reproducción del error:
> -----------------------
> C:\Archivos de programa\PostgreSQL\8.1\bin>psql postgres postgres
> Bienvenido a psql 8.1.1, la terminal interactiva de PostgreSQL.

Ok, dejemos en claro que
1. el error no tiene nada que ver con COPY CSV, es mas general que eso

2. el esquema donde tengas la tabla es irrelevante; el archivo de datos
tambien. Puedo reproducir el error con un simple "COPY foo FROM
archivo". Ni la tabla ni el archivo es necesario que existan.

3. los caracteres raros que veo aca abajo me sugieren que tienes un
problema en la configuracion de tu servidor. A saber,

> Digite: \copyright para ver los tÚrminos de distribuci¾n

Aca, en la palabra "terminos" yo veo una U mayuscula con acento agudo en
lugar de una e con acento agudo, y en la palabra "distribucion" veo un
simbolo 3/4 en lugar de una o con acento agudo. Es eso mismo lo que ves
en tu consola?

Si es asi, permiteme indicarte que tu sistema esta mal configurado :-)

Ahora, dado que el problema no se manifiesta en otra base de datos, me
entra una duda. Por favor muestra lo que dice lo siguiente:

select name, setting from pg_settings where name like 'lc_%';

Si el servidor no esta configurado con un locale que soporte la
codificacion UTF-8, entonces una opcion es decir que tu problema es
error de piloto. Por mucho que se pueda cambiar la codificacion al
momento de crear una base de datos, _no debes_ seleccionar una
codificacion que no sea la misma que la que declara el locale.

En mi ejemplo, si hago
initdb -E UTF8 --locale es_CL
puedo reproducir el problema. Pero la configuracion es erronea, puesto
que el locale es_CL no soporta la codificacion UTF8. En cambio, si hago

initdb -E UTF8 --locale es_CL.UTF-8
entonces no puedo reproducir el problema, es decir, el servidor se
comporta como es esperable.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera escribió:
> Oswaldo Hernández escribió:
>
> 1. el error no tiene nada que ver con COPY CSV, es mas general que eso
>
> 2. el esquema donde tengas la tabla es irrelevante; el archivo de datos
> tambien. Puedo reproducir el error con un simple "COPY foo FROM
> archivo". Ni la tabla ni el archivo es necesario que existan.
>
> 3. los caracteres raros que veo aca abajo me sugieren que tienes un
> problema en la configuracion de tu servidor. A saber,
>
>
>>Digite: \copyright para ver los tÚrminos de distribuci¾n
>
>
> Aca, en la palabra "terminos" yo veo una U mayuscula con acento agudo en
> lugar de una e con acento agudo, y en la palabra "distribucion" veo un
> simbolo 3/4 en lugar de una o con acento agudo. Es eso mismo lo que ves
> en tu consola?
>
Si, la consola de windows es muy puñetera, no he podido configurarla para que psql muestre bien los
caracteres. Aunque se modifique con chcp, siguen sin salir bien.

> Si es asi, permiteme indicarte que tu sistema esta mal configurado :-)

Es muy posible, este es un sistema para pruebas y puede que no tenga demasiado cuidado con algunas
cosas.

> Ahora, dado que el problema no se manifiesta en otra base de datos, me
> entra una duda. Por favor muestra lo que dice lo siguiente:
>
> select name, setting from pg_settings where name like 'lc_%';

postgres=# select name, setting from pg_settings where name like 'lc_%';
name | setting
-------------+--------------------
lc_collate | Spanish_Spain.1252
lc_ctype | Spanish_Spain.1252
lc_messages | es_ES.UTF8
lc_monetary | spanish_spain.1252
lc_numeric | spanish_spain.1252
lc_time | spanish_spain.1252
(6 filas)

El lc_messages esta modificado manualmente debido a un problema que hubo con entre python y los
mensajes de la base de datos. Esto no lo solucionó, pero al parecer olvide restablecerlo a su valor
original.

>
> Si el servidor no esta configurado con un locale que soporte la
> codificacion UTF-8, entonces una opcion es decir que tu problema es
> error de piloto. Por mucho que se pueda cambiar la codificacion al
> momento de crear una base de datos, _no debes_ seleccionar una
> codificacion que no sea la misma que la que declara el locale.
>
> En mi ejemplo, si hago
> initdb -E UTF8 --locale es_CL
> puedo reproducir el problema. Pero la configuracion es erronea, puesto
> que el locale es_CL no soporta la codificacion UTF8. En cambio, si hago
>
> initdb -E UTF8 --locale es_CL.UTF-8
> entonces no puedo reproducir el problema, es decir, el servidor se
> comporta como es esperable.
>

Tienes razón, he vuelto a poner a lc_messages en su valor original Spanish_Spain.1252 y el error ha
desaparecido.

La configuracion es_ES.UTF8 no existe en windows.
¿No deberia haber aparecido algun warning en el log debido a la configuración errónea?

Aprovecho para consultar cual seria el locale correcto en windows para una codificación UTF8.

No he conseguido hacer el initdb en windows con:
--locale=es_ES.UTF-8
--locale=Spanish_Spain.UTF-8
--locale=Spanish_Spain.65001 (en teoria este deberia ser el correcto)

initdb siempre dice que el nombre de la configuración local no es válido y se será iniciado con la
configuración local Spanish_Spain.1252

Unicamente he podido realizar el initdb con locale Spanish_Spain.1252 (ANSI - Latin I) o
Spanish_Spain.28605 (ISO 8859-15 Latin 9)

¿Que repercusiones puede tener el que el cluster se haya inicializado con utf8 (-D UTF8) y el locale
como latin9 o windows ansi?

Gracias.

--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

Oswaldo Hernández escribió:

> >En mi ejemplo, si hago
> >initdb -E UTF8 --locale es_CL
> >puedo reproducir el problema. Pero la configuracion es erronea, puesto
> >que el locale es_CL no soporta la codificacion UTF8. En cambio, si hago
> >
> >initdb -E UTF8 --locale es_CL.UTF-8
> >entonces no puedo reproducir el problema, es decir, el servidor se
> >comporta como es esperable.
>
> Tienes razón, he vuelto a poner a lc_messages en su valor original
> Spanish_Spain.1252 y el error ha desaparecido.
>
> La configuracion es_ES.UTF8 no existe en windows.

Aparentemente no se puede.

http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00062.php

Una posible solucion es que te cambies a una plataforma mas razonable.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera escribió:

>
> Una posible solucion es que te cambies a una plataforma mas razonable.

El desarrollo va dirigido a las dos plataformas, por eso hemos empezado por la mas problemática.

Gracias por tu tiempo.

Saludos,

--
*****************************************
Oswaldo Hernández
oswaldo(at)soft-com(dot)es
*****************************************

Oswaldo Hernández escribió:
> Alvaro Herrera escribió:
>
> >
> >Una posible solucion es que te cambies a una plataforma mas razonable.
>
> El desarrollo va dirigido a las dos plataformas, por eso hemos empezado por
> la mas problemática.

http://archives.postgresql.org/pgsql-hackers/2006-06/msg01042.php

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support