Excerpts from Fabricio's message of jue jun 07 16:29:20 -0400 2012: > > ¿Qué sistema operativo estás usando? ¿Qué sistema de archivos? ¿Tienes > > fsync=off? Describe el sistema de almacenamiento: ¿RAID? ¿Hay caché de > > escritura que pueda haber fallado? > > > > Slackware 13.1 > ext4 > fsync=on > Son dos discos en RAID 1, el RAID es por hardware HP ciss
Hum. Slackware 13.1 cumple dos años este mes, ¿no? ¿no habrá un bug en el kernel? > > Quizas si fue esta la causa, su hay un mensaje de error sobre la particion y > la cache: > > > Jun 7 01:32:55 SERVIDOR kernel: IRQ 71/cciss0: IRQF_DISABLED is not > guaranteed on shared IRQs > Jun 7 01:32:55 SERVIDOR kernel: cciss/c0d0: p2 size 1127850720 exceeds > device capacity, limited to end of disk > Jun 7 01:32:55 SERVIDOR kernel: JBD: barrier-based sync failed on > cciss!c0d0p2-8 - disabling barriers > Jun 7 01:32:55 SERVIDOR kernel: JBD: barrier-based sync failed on > cciss!c0d0p2-8 - disabling b > > Despues de los primeros errores el servidor se reinicio y al entrar marco > esos mensajes y fue cuando ya no estaban los archivos del pg_xlog Bueno, si los archivos de pg_xlog se perdieron, la única explicación posible es un problema en el kernel o en el filesystem :-( Creo que hay que señalar que si le das un pg_resetxlog para salir de un problema de archivos pg_xlog faltantes, entonces se sabe que la base de datos está en un estado inconsistente y DEBES hacer un dump/restore; no es permisible continuar operando con la misma base de datos. -- Álvaro Herrera <[email protected]> - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
