Обсуждение: Invalid Page Header Error
Hello, We had a server crash and when restarting postgres it works, except some "Invalid Page Header Error" : I already try VACUUM / FULL / ANALYSE but same error Even when doing a pg_dumpall, we have this problem. $ pg_dumpall >/dev/null pg_dump: ERREUR: en-tête de page invalide dans le bloc 6142 de la relation « articles_hs » pg_dump: La commande SQL de sauvegarde du contenu de la table « articles_hs » a échoué : échec de PQendcopy(). pg_dump: Message d'erreur du serveur : ERREUR: en-tête de page invalide dans le bloc 6142 de la relation « articles_hs » pg_dump: La commande était : COPY rma.articles_hs (arths_id, status, no_art_bw, no_art_fourn, desc_fr, desc_de, price_public, rabais_art, rabais_quant, rabais_fam, no_page, no_fourn, nb_stock, type_art, nb_embal, unit_vente, arths_update, arths_price_v, arths_price_c, arths_garmin_enabled, arths_rma_enabled) TO stdout; pg_dumpall : échec de pg_dump sur la base de données « rma », quitte I read a lot of formus, but never a clear solution, what could we do to solve this problem ? (Except from taking the previous backups ?) If we loose data it's not a problem, I just want to know how postgres can clean himself again... Thanks a lot for any advice... Denis
Denis BUCHER wrote:
> Hello,
>
> We had a server crash and when restarting postgres it works, except some
> "Invalid Page Header Error" :
Data corrupted on disk. Either:
1. You have bad hardware
2. You have disks lying about fsync
3. You have fsync turned off.
> I already try VACUUM / FULL / ANALYSE but same error
>
> Even when doing a pg_dumpall, we have this problem.
Yes - a disk-block ("page") on disk has invalid pointers ("header").
> I read a lot of formus, but never a clear solution, what could we do to
> solve this problem ? (Except from taking the previous backups ?)
If you can restore from a backup, do that.
> If we loose data it's not a problem, I just want to know how postgres
> can clean himself again...
You might well be able to dump tables individually, apart from the one
that's corrupted. You can usually select out rows apart from those that
are corrupted. There's no easy way to identify all corrupted rows
without reading them. There's no guarantee that rows might be corrupted
in a way you don't notice at first.
There's no tool to fix these problems, because there's no simple pattern
to them if you have hardware failure. Even if there was, you could never
trust the data without comparing it to a backup.
So - make sure your last backup restores OK. Check your hardware works.
Make sure you have fsync turned on and your disks are syncing when they
say they do.
--
Richard Huxton
Archonet Ltd
Hello Richard,
Just to keep you informed...
Richard Huxton a écrit :
>> We had a server crash and when restarting postgres it works, except some
>> "Invalid Page Header Error" :
>
> Data corrupted on disk. Either:
> 1. You have bad hardware
> 2. You have disks lying about fsync
> 3. You have fsync turned off.
>
>> I already try VACUUM / FULL / ANALYSE but same error
>>
>> Even when doing a pg_dumpall, we have this problem.
>
> Yes - a disk-block ("page") on disk has invalid pointers ("header").
>
>> I read a lot of formus, but never a clear solution, what could we do to
>> solve this problem ? (Except from taking the previous backups ?)
>
> If you can restore from a backup, do that.
>
>> If we loose data it's not a problem, I just want to know how postgres
>> can clean himself again...
>
> You might well be able to dump tables individually, apart from the one
> that's corrupted.
Ok that's a good idea...
> You can usually select out rows apart from those that
> are corrupted. There's no easy way to identify all corrupted rows
> without reading them. There's no guarantee that rows might be corrupted
> in a way you don't notice at first.
>
> There's no tool to fix these problems, because there's no simple pattern
> to them if you have hardware failure. Even if there was, you could never
> trust the data without comparing it to a backup.
>
> So - make sure your last backup restores OK. Check your hardware works.
> Make sure you have fsync turned on and your disks are syncing when they
> say they do.
Yes finally we started back from the last backup (a script that dump
database and gzip it everyday is really the best and minimal backup tool
that saved my life more than once :-)))
Denis
I have quite the same problem. When I lauch a vacuumdb, I have an error : ERREUR: en-tête de page invalide dans le bloc 39639 de la relation base/16384/599662 With a SELECT * FROM pg_catalog.pg_largeobject Result is ERREUR: en-tête de page invalide dans le bloc 39639 de la relation base/16384/599662 I suppose that the data of LargeObject 599662 are corrupted... Question is : How I could I know where this LargeObject is used ? I can, of course, use the "zero_damaged_pages = on" option in postgresql.conf. Then dump/restore. But in this case I didn't know where this corrupted LargeObject is used... If you have an idea... Thank you in advance. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Invalid-Page-Header-Error-tp1925403p5774671.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Carlo Curatolo wrote: > When I lauch a vacuumdb, I have an error : ERREUR: en-tête de page invalide > dans le bloc 39639 de la relation base/16384/599662 > > With a > SELECT * FROM pg_catalog.pg_largeobject > > Result is > ERREUR: en-tête de page invalide dans le bloc 39639 de la relation > base/16384/599662 > > I suppose that the data of LargeObject 599662 are corrupted... That is not the OID of a large object, but of a table. What do you get for SELECT oid, relname, relkind FROM pg_class WHERE relfilenode = 599662; > Question is : How I could I know where this LargeObject is used ? > > I can, of course, use the "zero_damaged_pages = on" option in > postgresql.conf. Then dump/restore. > But in this case I didn't know where this corrupted LargeObject is used... That could result in *all* your large objects or something else to get destroyed... You have some kind of data corruption. Have there been any crashes or unusual occurrences lately? The best thing would be to check your hardware thoroughly and restore the database from a backup. Yours, Laurenz Albe
Thanks for the help. SELECT oid, relname, relkind FROM pg_class WHERE relfilenode = 599662; --> returns nothing. No crash occurs, I have tested the hardware (memory, harddisks, RAID5, stability test...) I have made a little program to read all the LargeObject of my tables, they are all readable. So, I restart postgreSQL with "zero_damaged_pages = on", lauch a vacuumlo and vacummdb, restart with "zero_damaged_pages = off", the recheck all the LargeObject of my tables. The error do no occurs anymore... Seems that the corrupted LargeObject was not used...possible ? Regards. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Invalid-Page-Header-Error-tp1925403p5774724.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Carlo Curatolo wrote: > SELECT oid, relname, relkind FROM pg_class WHERE relfilenode = 599662; --> > returns nothing. Maybe the wrong database? Try to find out which object this file belongs to (maybe with oid2name). > No crash occurs, I have tested the hardware (memory, harddisks, RAID5, > stability test...) Good. > I have made a little program to read all the LargeObject of my tables, they > are all readable. Good. > So, I restart postgreSQL with "zero_damaged_pages = on", lauch a vacuumlo > and vacummdb, restart with "zero_damaged_pages = off", the recheck all the > LargeObject of my tables. You mean, you ran pg_dumpall, created a new cluster and imported, right? If you continue running the damaged cluster, the next problem is waiting just around the bend. > The error do no occurs anymore... > > Seems that the corrupted LargeObject was not used...possible ? I maintain that it was a table or index that was corrupted, not a large object. Yours, Laurenz Albe
Yes I ran pg_dumpall, create a new cluster and import. Everything seems fine now. How can I prevent that ? -- View this message in context: http://postgresql.1045698.n5.nabble.com/Invalid-Page-Header-Error-tp1925403p5774728.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Carlo Curatolo wrote: > Yes I ran pg_dumpall, create a new cluster and import. Ok, cool. > Everything seems fine now. > > How can I prevent that ? Prevent data corruption? Have good hardware, run the latest PostgreSQL fixes... Most of all, have a good backup so that you can recover. Yours, Laurenz Albe