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