Invalid Page Headers

Поиск
Список
Период
Сортировка
От Thomas F. O'Connell
Тема Invalid Page Headers
Дата
Msg-id B8F30540-C0A5-4CF7-8DB2-867DFF25E58D@sitening.com
обсуждение исходный текст
Ответы Re: Invalid Page Headers
Список pgsql-admin
I've got a database that reported this error yesterday morning after
an UPDATE statement:

ERROR:  invalid page header in block 34 of relation "pg_toast_167245"

Later in the day, it reported this one:

ERROR:  invalid page header in block 199 of relation "<table1>_pkey"

this time after a SELECT.

Before these errors had been brought to my attention, I was looking
late that night at a long-running query on an unrelated table. There
was a query that should've finished in seconds that was taking hours.
I later heard from a developer that there were some deadlock-related
issues with the query in question, and the development team wound up
issuing:

pg_ctl kill QUIT [process_id]

to get rid of the problem query this morning, which was a relatively
unimportant SELECT.

Then, shortly thereafter, they began seeing yet another invalid page
header:

invalid page header in block 4369 of relation "<table2>"

So there are currently three separate relations exhibiting invalid
page errors.

This box is a Debian 3.1 box running a custom Linux 2.6.10 #6 SMP
kernel. Postgres 8.1.3 was compiled from source. pgpool 3.0.1, also
built from source, is used by some parts of the application layer.
The system is running on an ext3 filesystem, WAL is on a 4-disk RAID
10 running JFS, and data is on a 12-disk RAID 10 running JFS. I'm not
seeing any signs of apparent kernel or hardware errors in the system
and kernel logs.

Also see nearby thread of a troubling error from the night before the
first sight of invalid page headers:

http://archives.postgresql.org/pgsql-general/2006-04/msg00746.php

Is there any way in which this could be related to the invalid page
headers?

Based on this thread:

http://archives.postgresql.org/pgsql-general/2005-11/msg01140.php

I'm a little nervous about the prospects for analysis and recovery
here. Any thoughts?

Is there a risk that if we took postgres offline in this state that
it would not come back up?

--
Thomas F. O'Connell
Database Architecture and Programming
Sitening, LLC

http://www.sitening.com/
3004 B Poston Avenue
Nashville, TN 37203-1314
615-260-0005 (cell)
615-469-5150 (office)
615-469-5151 (fax)


В списке pgsql-admin по дате отправления:

Предыдущее
От: tony
Дата:
Сообщение: Re: downward dump compatibility
Следующее
От: "Thomas F. O'Connell"
Дата:
Сообщение: Re: Invalid Page Headers