Re: En-tête de page

Lists: pgsql-fr-generale
From: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: En-tête de page invalide dans le bloc ...
Date: 2005-01-17 15:38:19
Message-ID: 20050117153819.GA21662@newtech.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Bonjour à tous,

Vendredi soir, lors d'une mise à jour un peu lourde (quelques millions
d'UPDATE) suivie d'un VACUUM, une table de ma base PostgreSQL a été
corrompue. Désormais, toute requête impliquant cette table aboutit à
l'erreur :

ERREUR: En-tête de page invalide dans le bloc 38320 de la relation "rel_fonctio"

Cette erreur est systématique et donc parfaitement reproductible
quelque soit la requête.

J'utilise PostgreSQL 7.4.6 (Debian Testing) sur Bi-Opteron (noyau et
libc 64 bits, le reste en 32 bits).

J'ai donc 2 questions :

1. Avez-vous déjà rencontré cette erreur ? Si oui, savez-vous quelle
en est la cause ?

Bien évidemment, j'ai effectué une recherche sur Google et je suis
tombé sur 2 threads différents. L'un conclut que le problème est
d'ordre matériel, l'autre qu'il s'agit d'un bogue de PostgreSQL.
Cela ne m'aide pas beaucoup.

2. Savez vous s'il est possible d'y remédier autrement qu'en
regénérant complètement la base ou la table incriminée ?

Je vous remercie par avance,

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


From: Jean-Christophe Arnu <arnu(at)paratronic(dot)fr>
To: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: En-tête de page
Date: 2005-01-17 16:08:43
Message-ID: 41EBE30B.5070609@paratronic.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Sébastien Dinot m'expliquait (le 17.01.2005 16:38):

>Bonjour à tous,
>
>Vendredi soir, lors d'une mise à jour un peu lourde (quelques millions
>d'UPDATE) suivie d'un VACUUM, une table de ma base PostgreSQL a été
>corrompue. Désormais, toute requête impliquant cette table aboutit à
>l'erreur :
>
>ERREUR: En-tête de page invalide dans le bloc 38320 de la relation "rel_fonctio"
>
>
Ca me rappelle quelque-chose, une manip que j'avais fait en temps que
single user sur une base pour réparer les tables système
pg_attributes_*? J'avais commencé par faire des opérations dans le
mauvais ordre [1]. Il est possible que tu aies eu (je ne sais pas
comment, mais c'est peut être une piste?) un problème du même type et
qu'un petit passage en single user pourrait te permettre de réparer la
chose (voir ce que je fais dans ma manip)...
J'espère que ça permettra de réparer la chose en un premier temps?

A+

[1] http://www.postgresqlfr.org/?q=node/view/49

--
Jean-Christophe Arnu
Paratronic


From: Jean-Paul Argudo <jean-paul(at)argudo(dot)org>
To: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
Cc: Jean-Christophe Arnu <arnu(at)paratronic(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: En-tête de page
Date: 2005-01-17 18:39:57
Message-ID: 41EC067D.5080706@argudo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

>> Vendredi soir, lors d'une mise à jour un peu lourde (quelques millions
>> d'UPDATE) suivie d'un VACUUM, une table de ma base PostgreSQL a été
>> corrompue. Désormais, toute requête impliquant cette table aboutit à
>> l'erreur :
>>
>> ERREUR: En-tête de page invalide dans le bloc 38320 de la relation
>> "rel_fonctio"

Renseignements pris (perso je n'ai jamais eu de telle erreur, pourtant
j'utilise PG de manière intensive aussi), on me dit que tu dois tout
d'abord arrêter PG quand cela t'arrive, et faire une sauvegarde à froid,
soit mettre de côté tous les fichiers de $PGDATA... (postmaster arrêté
donc).

Ensuite, il te faudra te remettre un tout petit peu à l'anglais et
poster sur pgsql-hackers, la liste des hackers.

Apparement, l'homme de la situation c'est Tom Lane, une fois de plus!

Et il semble qu'il ne lit pas le Français.

> Ca me rappelle quelque-chose, une manip que j'avais fait en temps que
> single user sur une base pour réparer les tables système [...]
> [1] http://www.postgresqlfr.org/?q=node/view/49

Oui, essaie ce qu'à déjà fait Jean-Christophe, ça pourrait te sauver la
mise..

Dans le pire des cas, il te faudra restaurer... Mais franchement, ça
m'inquiète un peu ton histoire, PG 7.4.6 est réputée pour être solide...

As tu regardé un peu du côté du système?.. Ça a donné quoi?..

Bon courage Sébastien,

--
Jean-Paul Argudo


From: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: En
Date: 2005-01-19 08:52:15
Message-ID: 20050119085215.GA21934@newtech.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Bonjour à tous,

Jean-Christophe, tu m'as sauvé !

J'ai lu la page dont tu avais indiqué l'url [3] et j'ai soigneusement
évité de faire ce qu'il ne fallait pas faire. (c;

J'ai donc procédé ainsi :

- arrêt du serveur PostgreSQL ;
- lancement du serveur en mode « single user » ;
- VACUUM FULL ANALYZE ;
- REINDEX DATABASE mabase ;

Le serveur m'a indiqué qu'il avait trouvé des erreurs et qu'il allait
les corriger (vas-y mon gars, ne te gêne pas mais j'aurais aimé que tu
m'en dises un peu plus).

J'ai ensuite relancé le serveur normalement. Après quelques requêtes
basiques pour vérifier que la base était d'aplomb, j'ai relancé le
traitement qui avait abouti à la corruption de la table. Celui-ci
s'est, cette fois, terminé fructueusement...

Bref, cette expérience me laisse perplexe. D'un côté, n'ayant pu
déterminer la cause du problème, je crains de le voir se reproduire un
de ces jours. De l'autre, PostgreSQL s'est tout de même montré capable
de retomber sur ses pattes.

En tout cas, je te remercie pour ce pointeur salvateur. Tu avais bien
fait de relater tes mésaventures de l'époque. Nous devrions peut-être
tous faire de même afin de constituer une base de connaissance sur les
problèmes qui peuvent survenir et la manière de les résoudre.

Sébastien

[1] http://www.postgresqlfr.org/?q=node/view/49

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


From: Jean-Christophe Arnu <arnu(at)paratronic(dot)fr>
To: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>, Pgsql Fr Generale <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: En
Date: 2005-01-19 09:08:09
Message-ID: 41EE2379.6020900@paratronic.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Sébastien Dinot m'expliquait (le 19.01.2005 09:52):

>Bonjour à tous,
>
>Jean-Christophe, tu m'as sauvé !
>
>J'ai lu la page dont tu avais indiqué l'url [3] et j'ai soigneusement
>évité de faire ce qu'il ne fallait pas faire. (c;
>
>J'ai donc procédé ainsi :
>
>- arrêt du serveur PostgreSQL ;
>- lancement du serveur en mode « single user » ;
>- VACUUM FULL ANALYZE ;
>- REINDEX DATABASE mabase ;
>
>Le serveur m'a indiqué qu'il avait trouvé des erreurs et qu'il allait
>les corriger (vas-y mon gars, ne te gêne pas mais j'aurais aimé que tu
>m'en dises un peu plus).
>
>
Peut être qu'il existe des options de verbosité dans postmaster. En tout
cas VACUUM FULL VERBOSE ANALYZE aurait peut être donné plus d'information?
Je penche pour un index corrompu....

--
Jean-Christophe Arnu
Paratronic