Re: timestamp out of range

> Guillermo Muñoz escribió:
>> Alvaro:
>> En cuanto disponga de datos te paso la misma consulta por psql, la estoy
>> sacando con el pgadmin
>>
>> ahora me sale otro error cuando hago un pg_dump, porque empece a limpiar
>> tablas que podian tener algun dato corrupto y el pg_dump avanzo mas pero
>> cambio el error que me tira:
>>
>> pg_dump: Error message from server: ERROR: cache lookup failed for index
>> 104251
>
> Hummm, esto tiene pinta de problema mas serio. Quizas el hardware esta
> fallando por algun motivo ... disco malo, quizas ram mala? Fijate en el
> log del sistema operativo; hay algo raro? Mira tambien los mensajes de
> SMART del disco. Si puedes, baja el servicio por unas horas y dejale
> corriendo memtest86. Tambien prueba dejandole cpuburn corriendo unas
> horas. En hardware que este bueno, no deberia pasar nada, pero si es
> limitrofe y falla en condiciones extremas, es posible que arroje algun
> error, en cuyo caso deberias cambiarlo.

y asi fue, esta mañana el servidor estaba tirando errores de inode y no
respondia ni siquiera a la consola. se hizo el fsck de la particion con un
livecd y se pudo acceder a los archivos.
se levanto la base de datos, pero el pg_dump siguio tirando errores con las
fecha.
el tema es ¿que tan confiable queda el servidor despues de este problema?.
antes de la ecatombe, se instalo una placa scii para la unidad de backup.

Saludos
Guillermo Muñoz

>
>
>> que significa, esta corto de cache?
>> te comento, restaure la configuracion original de la instalacion
>> shared_buffers=32MB
>> max_fsm_pages=204800
>
> No, el mensaje de "cache lookup failed" no tiene nada que ver con el
> tamaño del cache.
>
>> y el log me esta pidiendo el doble
>
> A que te refieres? No has mostrado ningun error que pueda tener que ver
> con eso.
>
>> estoy en un servidor de 8 GB de ram, 4 discos de 72 GB con un raid 3+1
>> (espejado). lo puedo tunear bastante, pero cuando lo hice los procesos
>> llegaban a 3GB y saltaban por out of memory.
>> (a los procesos les digo a funciones de carga)
>> te paso el dato por si tiene que ver
>
> Quizas el work_mem es demasiado alto? No tiene nada que ver con lo de
> arriba en todo caso.
>
> Raid 3+1 es lo mas raro que he escuchado. Lo mas recomendable para un
> servidor de datos es 1+0.
>
> --
> Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13'
> 56.4"
> "Las navajas y los monos deben estar siempre distantes" (Germán Poo)
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.28/1021 - Release Date:
> 21/09/2007 02:02 p.m.
>
>