Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je rencontre l'erreur suivant lors d'un dump sur une base de données particulière sur une table contenant des données binaire (ex: image, pdf,...) de type bytea.
Voici l'erreur en question:
pg_dump: Error message from server: ERROR: could not access status of transaction 256212738
DETAIL: Could not read from file "pg_clog/00F4" at offset 81920: Input/output error.
En regardant dans PGDATA/pg_clog le fichier 00F4 existe bien mais ne peut être lu.
Ex: un less pg_clog/00F4 renvoie l'erreur : read error
Environnement sous linux, version postgresql 9.3.5.
Sachant qu'il n'y a pas de sauvegarde dump à restaurer, est ce qu'il existe un moyen pour corriger le problème svp ?
Hors ligne
Petite rectification : postgresql 9.4.5 mais non 9.3.5
Personne une solution ?
Hors ligne
Il n'y a pas de solution simple. Les fichiers CLOG contiennent les informations de statut des transactions. Sans eux, PostgreSQL ne sait pas quels lignes sont visibles et quels lignes sont invisibles. Le seul truc à tester est de renommer 00F4 puis de créer un fichier 00F4 de la bonne taille et rempli d'octets nuls. Vous devriez pouvoir faire un dump mais vous ne retrouverez pas toutes les données. Il est même tout à fait possible que le dump ne soit pas complètement restaurable en cas de violation de certaines contraintes.
Et du coup, il va falloir vérifier ce disque et probablement à coup sûr le remplacer.
Guillaume.
Hors ligne
gleu > Merci pour ta réponse Guillaume.
En parcourant une à une les enregistrement de la table en question, on connait maintenant la ligne (1 champs dans cette ligne) qui pose problème.
Si je fais un DELETE de cette ligne et que je lance ensuite un VACUUM FULL sur la table, est ce que cela pourrait résoudre le problème ?
Hors ligne
Vous ne pourrez pas faire un DELETE de la ligne et un VACUUM FULL ne changera rien à ma connaissance. Dans ce cas, le mieux est de sauvegarder toute la base, sauf la table problématique, puis sauvegarder la table avec un COPY (SELECT... WHERE filtrant la ligne qui pose problème). Comme ça, vous aurez un dump propre. Il serait bien de tester que vous pouvez restaurer ce dump. Puis remplacement du disque, création d'une instance PostgreSQL et restauration du dump.
Guillaume.
Hors ligne
Je ne peux même pas faire un select * from table_corrompu where id <> id_corrompu ni un select * from table_corrompu where id > id_corrompu.
Il doit faire un fullscan le truc et çà pête.
donc la seule solution est elle remplacer 00f4 évoquait plus haut ? Comment cré t-on ce fichier de remplacement ?
Hors ligne
ah une autre idée faire un select en specifiant carrément la clé, donc de prendre le max(id) et select where id in (id_corrompu+1, id_corrompu+2, .. max(id)) je teste
Hors ligne
Ca ne le fait pas il existe egalement d'autre id corrompu.
Je reprend : donc la seule solution est elle remplacer 00f4 évoquait plus haut ? Comment cré t-on ce fichier de remplacement ?
Hors ligne
Je n'en vois pas d'autres mais c'est difficile à dire sans accéder à la machine et y passer un peu de temps. Pour créer ce fichier, je vois bien cette commande :
dd if=/dev/zero of=00F4 count=1 bs=8192Faites d'abord une copie intégrale de vos fichiers PostgreSQL (donc le PGDATA et les tablespaces).
Guillaume.
Hors ligne
Merci , en fin de compte on a restauré la table sans les lignes corrompues.
Merci à tous
Hors ligne
Pages : 1