Re: Erreur bloc dans pg_attrdef

Bonjour, suite à une mise à jour de sécurité (8.3.8 à 8.3.9), notre de base
de donnée rencontre des erreurs du genre :
ERREUR: en-tête de page invalide dans le bloc 4 de la relation « pg_attrdef
»
et le code d'erreur XX001 (retourné par l'application php).

Est-il possible de pouvoir récupérer ses données? Et d'où pourrait venir ces
différents problèmes?

Merci d'avance,

Nabil Servais

Le 06/01/2010 15:06, Servais Nabil a écrit :
> Bonjour, suite à une mise à jour de sécurité (8.3.8 à 8.3.9), notre de base
> de donnée rencontre des erreurs du genre :
> ERREUR: en-tête de page invalide dans le bloc 4 de la relation « pg_attrdef
> »
> et le code d'erreur XX001 (retourné par l'application php).
>
> Est-il possible de pouvoir récupérer ses données? Et d'où pourrait venir ces
> différents problèmes?
>

pg_attrdef est une table système. Et le problème que vous avez semble
être dû au disque. Vous avez eu des problèmes sur ce disque ? ou un
crash dernièrement ?

Il va falloir restaurer la dernière sauvegarde. Mais avant, il faut
savoir si le matériel est bon ou pas.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On ne voit pas d'erreurs disque dans les logs et aucun crash depuis 6 mois,
on a pourtant fait cette mise à jour sur d'autres serveurs sans rencontrer
de soucis.
On vient de remonter les données et toujours la même erreur mais pas sur la
même table.

2010/1/6 Guillaume Lelarge <guillaume(at)lelarge(dot)info>

> Le 06/01/2010 15:06, Servais Nabil a écrit :
> > Bonjour, suite à une mise à jour de sécurité (8.3.8 à 8.3.9), notre de
> base
> > de donnée rencontre des erreurs du genre :
> > ERREUR: en-tête de page invalide dans le bloc 4 de la relation «
> pg_attrdef
> > »
> > et le code d'erreur XX001 (retourné par l'application php).
> >
> > Est-il possible de pouvoir récupérer ses données? Et d'où pourrait venir
> ces
> > différents problèmes?
> >
>
> pg_attrdef est une table système. Et le problème que vous avez semble
> être dû au disque. Vous avez eu des problèmes sur ce disque ? ou un
> crash dernièrement ?
>
> Il va falloir restaurer la dernière sauvegarde. Mais avant, il faut
> savoir si le matériel est bon ou pas.
>
>
> --
> Guillaume.
> http://www.postgresqlfr.org
> http://dalibo.com
>

Le 06/01/2010 15:19, Servais Nabil a écrit :
> On ne voit pas d'erreurs disque dans les logs et aucun crash depuis 6 mois,
> on a pourtant fait cette mise à jour sur d'autres serveurs sans rencontrer
> de soucis.
> On vient de remonter les données et toujours la même erreur mais pas sur la
> même table.
>

Remonter les données ne suffit pas. Comme il s'agit d'une table système,
il faut détruire (ou plutôt renommer dans un premier temps) le
répertoire des données, lancer de nouveau initdb pour recréer ce
répertoire, puis restaurer la (les) sauvegarde(s).

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Le 06/01/2010 15:38, Servais Nabil a écrit :
> On a la même erreur sur une autre table mais pas sur une table système. Je
> penchais aussi sur un problème de disque, je pense que vous confirmez ma
> première hypothèse mais c'est étrange que le système ne remonte aucune
> erreur à propos des disques.
>

Si vous avez eu une erreur sur un autre fichier, je vous conseille
fortement de vérifier le disque sur lequel se trouvent les deux
fichiers. Car, même après la restauration, rien ne dit que vous n'aurez
pas d'autres problème si le disque a pris un coup.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Le 06/01/2010 16:03, Servais Nabil a écrit :
> Et pour les données corrompues, tout espoir est perdue?
>

La question est bizarre. Si la donnée est corrompue, on ne peut pas la
retrouver par définition.

Vous pouvez sauvegarder les autres bases si vous en avez (à condition de
ne pas avoir d'autres erreurs), mais celle qui a ce problème est
malheureusement trop endommagée. Plus exactement, il faudrait beaucoup
de temps et d'expertise (possibilité de se connecter par exemple) pour
avoir un pronostique plus sûr.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Bonjour,

Alors, on a changé de machine, réinitialiser un cluster, monter le dump.
Et encore une erreur de type : en-tête de page invalide dans le bloc 2 de la
relation "table". A la requete précédente, on obtient l'avertissement
suivant : ATTENTION: temporary file leak: File 65 still referenced.

Alors là je n'ai plus aucune idée.

2010/1/6 Guillaume Lelarge <guillaume(at)lelarge(dot)info>

> Le 06/01/2010 16:03, Servais Nabil a écrit :
> > Et pour les données corrompues, tout espoir est perdue?
> >
>
> La question est bizarre. Si la donnée est corrompue, on ne peut pas la
> retrouver par définition.
>
> Vous pouvez sauvegarder les autres bases si vous en avez (à condition de
> ne pas avoir d'autres erreurs), mais celle qui a ce problème est
> malheureusement trop endommagée. Plus exactement, il faudrait beaucoup
> de temps et d'expertise (possibilité de se connecter par exemple) pour
> avoir un pronostique plus sûr.
>
>
> --
> Guillaume.
> http://www.postgresqlfr.org
> http://dalibo.com
>

Le 07/01/2010 10:01, Servais Nabil a écrit :
> Bonjour,
>
> Alors, on a changé de machine, réinitialiser un cluster, monter le dump.
> Et encore une erreur de type : en-tête de page invalide dans le bloc 2 de la
> relation "table". A la requete précédente, on obtient l'avertissement
> suivant : ATTENTION: temporary file leak: File 65 still referenced.
>

Est-ce que vous utilisez des curseurs dans des transactions qui seraient
annulées (ROLLBACK) ? il y a eu un rapport de bug dans ce sens fin
décembre
(http://archives.postgresql.org/pgsql-bugs/2009-12/msg00243.php) il a
été corrigé par Heikki.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Le 07/01/2010 10:09, Guillaume Lelarge a écrit :
> Le 07/01/2010 10:01, Servais Nabil a écrit :
>> Bonjour,
>>
>> Alors, on a changé de machine, réinitialiser un cluster, monter le dump.
>> Et encore une erreur de type : en-tête de page invalide dans le bloc 2 de la
>> relation "table". A la requete précédente, on obtient l'avertissement
>> suivant : ATTENTION: temporary file leak: File 65 still referenced.
>>
>
> Est-ce que vous utilisez des curseurs dans des transactions qui seraient
> annulées (ROLLBACK) ? il y a eu un rapport de bug dans ce sens fin
> décembre
> (http://archives.postgresql.org/pgsql-bugs/2009-12/msg00243.php) il a
> été corrigé par Heikki.
>

Pour infos, voici le patch en question :

http://archives.postgresql.org/message-id/20091229174100.02E1E753FB7@cvs.postgresql.org

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com