Re: Postgres "invalid page header"

Florian,

my hardware

 >>> I am working with 7.4.1 under Linux (SuSE 8.1) The server is a HP
ProLiant DL 380-G3, 2x Intel Pentium4-Xeon, 2.8 GHz, 4 GB memory and a
RAID 5 system with ca. 500 GB diskspace (xfs file system)
 >>>
seems somewhat similar to yours: I have been using the 2.4.22 kernel. I
wanted do upgrade to a 2.6.X, but your experience ... (see below)

 >>>
 >>> When doing big transactions or changes (UPDATE several million rows
in one step) on a database with ca. 50 GB diskspace and ca 15 million
entries, PostGIS and lots of indexes, I get errors like
 >>>
 >>> ERROR: invalid page header in block 582024 of relation ...
 >>>
 >>> The error does not occur regularly. It seems to me that the error
is related with heavy load and heavy I/O . CPU and memory does not seem
the problem, according to my hotsanic tools.
 >
 >
 >
 > Hi
 >
 > I believe that I had a similar problem - but since that database in
question
 > was still running I thought it was releated to the 7.4.1 bug
regarding the
 > wrong alignment information.
 >
 > Our database is running on an 2x Xeon 2.66GHz, 2GB of RAM, and two 120GB
 > Drives (Seagate ST3120026AS) combined to a software-raid-1 volume
(using the
 > md driver). Postgres has it's data on an XFS-Filesystem (74GB). We
are using
 > kernel 2.6.6 with the "deadline" io-scheduler).
 >
 > We daily load about 2-3 million rows into the database (in one big
 > transaction). The first problem
 > that appeared where crashing selects - the "Invalid page header"-problem
 > appeared when I tried to upgrade to 7.4.2, in the "analyze" step
right after
 > fixing the wrong alignment info in the system table.


So, can I conclude that
a) the error happened with 7.4.1 and with 7.4.2 upgraded from 7.4.1 as
described in your posting
http://archives.postgresql.org/pgsql-general/2004-06/msg00647.php .
Are you sure that it does no longer occur in your "clean" install of 7.4.2?
b) this also happens with a 2.6 kernel so this is not a 2.4 kernel issue?

Reproducing the error is a bit difficult as it seems to occur only on
high load in big databases.

I'll try to isolate the problem on a smaller scale. Anybody on the air
who has had the problem on a smaller issue?

 >
 > Since we couldn't repair the database (and more and more selects
started to
 > crash), we dumped everything that was still dumpable, and
reinitialized the
 > database. The new database is now running for about 1 1/2 weeks, and
there
 > haven't been any problems until now.
 >
 > So - maybe it's really an XFS problem... Which version of linux are you
 > running?


2.4.22, see above. To isolate filesystem problems I'd like to try with a
NAS if I get one. Do you think this makes sense?

Greetings,

Hubert Fröhlich

--
-------------------------------------------------------------------------------
Dr.-Ing. Hubert Fröhlich
Bezirksfinanzdirektion München
Alexandrastr. 3, D-80538 München, GERMANY
Tel. :+49 (0)89 / 2190 - 2980
Fax  :+49 (0)89 / 2190 - 2997
hubert dot froehlich at bvv dot bayern dot de