Re: [pgsql-es-ayuda] Problemas con VACUUM

2013-02-16 Por tema Alvaro Herrera 
Jose David Verbel Tous escribió:
> Bueno días,
> 
> Hoy paso lo mismo, el servicio se reinicio ejecutando el mismo vacuum, sin
> embargo esta ves el log si me da lo siguiente:
> 
> 
> 
> 2013-02-16 07:28:02 COT11602 LOG:  proceso de servidor (PID 28161) fue
> terminado por una se?al 9: Killed

No es "lo mismo".  La otra caída claramente fue un SIGTERM, pero esta es
un SIGKILL.  Es muy posible que en esta caída esté involucrado el
OOM-Killer, pero en la anterior no pudo ser así.  Son dos problemas
diferentes.


-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] copy archivo csv

2013-02-16 Por tema Anthony 

El 17/02/2013 1:51, José Fermín Francisco Ferreras escribió:

Hola a todos!!

Estoy intentando hacer un copy de un archivo csv q tiene mas de 6 
millones de registros a postgresql 9.2, pero a la hora de ejecutarse 
me lanza el siguiente mensaje:


basedatos=# copy tabla from '/var/lib/postgresql/9.2/main/archivo.csv' 
with delimiter as ',' CSV QUOTE '"';

ERROR:  memoria agotada
DETALLE:  La cadena de 1006420404 bytes es demasiado larga para la 
recodificación.

CONTEXTO:  COPY tabla, línea 6294863

Como puedo hacer para q me copie todos los registros a la tabla??




ing. José Fermín Francisco Ferreras
San Francisco de Macorís, Rep. Dom.
Has probado hacer la carga con file_fdw(apéndice F.14.file_fdw de la 
documentación) , donde defines una FOREIGN TABLE y luego cargas poco a 
poco para tu "tabla", poniendo un filtro en el where o con limit y offset


ejemplo carga de valores en porciones de 100 : insert into "tabla" 
select * from "tu FOREIGN TABLE" limit 100 offset N



saludos

[pgsql-es-ayuda] copy archivo csv

2013-02-16 Por tema José Fermín Francisco Ferreras 
Hola a todos!!
Estoy intentando hacer un copy de un archivo csv q tiene mas de 6 millones de 
registros a postgresql 9.2, pero a la hora de ejecutarse me lanza el siguiente 
mensaje:
basedatos=# copy tabla from '/var/lib/postgresql/9.2/main/archivo.csv' with 
delimiter as ',' CSV QUOTE '"';ERROR:  memoria agotadaDETALLE:  La cadena de 
1006420404 bytes es demasiado larga para la recodificación.CONTEXTO:  COPY 
tabla, línea 6294863
Como puedo hacer para q me copie todos los registros a la tabla??



ing. José Fermín Francisco Ferreras 
San Francisco de Macorís, Rep. Dom.

Re: [pgsql-es-ayuda] Problemas con VACUUM

2013-02-16 Por tema Jose David Verbel Tous 
Bueno días,

Hoy paso lo mismo, el servicio se reinicio ejecutando el mismo vacuum, sin
embargo esta ves el log si me da lo siguiente:



2013-02-16 07:28:02 COT11602 LOG:  proceso de servidor (PID 28161) fue
terminado por una se?al 9: Killed
2013-02-16 07:28:02 COT11602 LOG:  terminando todos los otros procesos de
servidor activos
2013-02-16 07:28:02 COT32525bd WARNING:  terminando la conexión debido a
una falla en otro proceso servidor

Lo extraño es que hay otras BD en el cluster y a esas si se les ejecuta
bien el vacuum.

Descarto problemas de hardware

Algun bug de PostgreSQL (Ver 8.4.10)

La BD tiene algún problema ?

De hecho tengo contingencia de la BD en otro servidor y alla se ejecuta sin
problemas la restauración el vacuum.




2013/2/15 Hellmuth Vargas 

>
> Hola Lista
>
>
> **
>>
>> Suena a que el backend haciendo el vacuum recibió un SIGTERM, quizá por
>> falta de recursos, habría que ver si el oom killer fué el responsable ...
>> es linux?
>>
>
> Pero si hubiese sido una terminación  por memoria, no se
> hubiera caído todos los procesos que hacen parte del cluster de base de
> datos? se evidenciaría en el log algo como:
>
> FATAL vacuum analyze
> process (PID 22999) was terminated by signal 9: Killed
> LOG:  terminating any other  active server processes
> LOG: The Postmaster has informed me that some other backend died
> abnormally and possibly corrupted shared memory.
> FATAL:  The database system is in recovery mode
> fast shutdown request all server processes terminated; reinitializing
> shared memory and semaphores
> FATAL:  The database system is shutting down
>
>
> Pienso mas bien que le proceso fue terminado  'por las buenas' con un kill
> -15 o pg_terminate_backend(). No se que opinan ustedes?
>
>
>>
>
>>
>>
>>
>> On Friday, February 15, 2013 06:17:30 PM Jose David Verbel Tous wrote:
>>
>> Saludos,
>>
>>
>> Me ha ocurrido algo "extraño", durante la realización de un VACUUM
>> ANALYZE programado por cron a una BD este se ha cancelado y el log de
>> postgres me da lo siguiente:
>>
>>
>> 2013-02-15 00:11:54 COT27323bd FATAL:  terminando la conexión debido a
>> una orden del administrador
>>
>> 2013-02-15 00:11:54 COT27323bd SENTENCIA:  VACUUM ANALYZE;
>>
>>
>> Sin embargo unos segundos despues (29 seg) el motor sigue recibiendo
>> consultas.
>>
>>
>> Ya he revisado todos los logs de mi sistema (Ubuntu) para validar que
>> alguien a esa hora estuviera conectado y realizado un restart del servicio.
>>
>>
>>
>> Que pudo haber pasado ?
>>
>>
>> Pdta: Este VACUUM se ejecuta de manera periodica sobre la misma base y
>> nunca habia pasado esto.
>>
>>
>>
>> --
>>
>> Jose David
>>
>>
>>
>>
>> --
>>
>> Postgresql Tips en español para la comunidad de México e Hispanoamérica.
>>
>> http://postgresql.org.mx
>>
>>
>>
>> Postgresql México en Twitter
>>
>> https://twitter.com/PgsqlMx
>>
>>
>>
>> Twitter account for news sharing
>>
>> https://twitter.com/iCodeiExist
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
>



-- 

*Jose David
*