| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Fede (dot) <elcotorro(at)gmail(dot)com> |
| Cc: | gilberto(dot)castillo <gilberto(dot)castillo(at)etecsa(dot)cu>, Marcelo Robin <marcelorobin(at)gmail(dot)com>, Lista Postgres <pgsql-es-ayuda(at)postgresql(dot)org> |
| Subject: | Re: perdida de informacion |
| Date: | 2011-05-05 13:01:41 |
| Message-ID: | 1304600225-sup-8980@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-es-ayuda |
Excerpts from Fede .'s message of jue may 05 09:48:08 -0300 2011:
> y con respecto al de linux que se corrompieron 2 registros, te paso el
> error que daba el dump
>
> Failed to backup database : pg_dump failed :
> pg_dump: la orden SQL falló
> pg_dump: Mensaje de error del servidor: ERROR: invalid memory alloc
> request size 18446744073709551610
Efectivamente esto es indicador de que algo se corrompió. Difícil decir
como, eso sí.
Curiosamente la representación en binario del número
18446744073709551610 es
1111111111111111111111111111111111111111111111111111111111111010
Me pregunto si puede haber pasado algo como una secuencia de prueba
automática del disco o controladora que decidió sobreescribir algunos
bytes. He visto cosas como esta en controladoras de SAN
sobreescribiendo bloques completos con secuencias de números
consecutivos.
--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fede . | 2011-05-05 13:13:56 | Re: perdida de informacion |
| Previous Message | Daniel Orozco | 2011-05-05 12:59:46 | Utilidad de pg_temp y pg_toast_temp |