Re: PANIC: ERRORDATA_STACK_SIZE exceeded

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
*****************************************