> On 10/04/2019, at 9:37 AM, Jaime Casanova <jaime.casan...@2ndquadrant.com>
> wrote:
>
> On Tue, 9 Apr 2019 at 14:17, Carlos Montecel <carlos.monte...@gmail.com>
> wrote:
>>
>> Estimado Jaime
>>
>> Mil disculpas por la omisión. La version es 9.2 y esta sobre centos
>>
>
> y por qué el script para sacar el dump lo sacas desde windows? bueno,
> eso no es importante
>
>> El comando : select relname, relkind from pg_class where relfilenode =
>> 166094; retorno "r" de tabla... Se puede hacer algo sobre la misma?? Al
>> menos para proceso de migración a otro HW…
>>
Pregunta, es posible revisar si la tabla dañada es una tabla no importante o
tabla de paso usada por algún proceso ?
> la segunda opción es la dolorosa, una solución a tu problema es poner
> en postgresql.conf la siguiente línea "zero_damaged_pages = on" y
> reiniciar el servicio.
> el problema de eso es que las páginas con errores serán enceradas
> (osea, rellenadas con ceros) si al tratar de leerlas da el error que
> mostraste arriba; lo que significa que vas a perder datos. peor que
> eso, es posible que no puedas restaurar el backup que saques porque al
> desaparecer ciertos datos podrían violarse algunos foreign key lo que
> significa que tendrías que cargar el backup en partes, primero
> pre-data y data y luego post-data para que puedas determinar si la
> creación de algún foreign key falla y puedas tratar de arreglar el
> problema.
>
> --
> Jaime Casanova www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
