From: | G u i d o B a r o s i o <gbarosio(at)uolsinectis(dot)com(dot)ar> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | invalid page header |
Date: | 2004-11-18 14:37:41 |
Message-ID: | 20041118143741.35AE86C9B9@honorio.sinectis.com.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Guys,
Sorry for writing here. The point is that google does not helps very much with this error message, and the lists also, cause they throw different posible diagnosis for the same problem. And I think that the creators of the "beast" will further know what it's going on, or at least give me an approach/howto.
PostgreSQL 7.4.2
Intel Xeon 2.8 * 8
Kernel 2.4.24-ck1 #5
SCSI disk.
4 gb RAM.
The message:
ERROR: invalid page header in block 90259 of relation "dat_cc_fail_auths"
When?
With almost any operation involving the relation "dat_cc_fail_auths"
This relation was created yesterday, droped cause I've found this error, and recreated again (also, a message pointing to a log file not found, or alike [050F, wall?], was printed yesterday), but the message still remains the same.
I am worry about a hardware problem.
Other synthomas.
1) 15 days ago, a vmtstat command segfaulted several times.
2) other relations, in other db's, began throwing messages, like the above, solved by a reindex force or recreate of the table. (not a good bussinnes, prd box)
3) top command died also, dunno why yet.
But...I haven't receive any other alerts or messages in log files (system logs reviewed) pointing me to problems. Above errors could not be so, and be just a random error going arround, coincidence and nothing else. Dunno.
So, I am not sure about this, I meant, I don't have a real pointer to a real problem. The message printed by postgres, invalid page..., seems to be ambigous when speaking about the root of the problem (an abnormal shutdown could lead into an error like this, a hardware problem could lead into this, and further circunstances, yah? well..wich ones?)
My point, I would like to design a plan in order to find the real problem and minimize the eventual downtime. As told earlier, this is a prd box.
The following snapshot is a top, while a reindex is running.
2:23pm up 16 days, 17:19, 5 users, load average: 2.18, 2.36, 2.00
96 processes: 90 sleeping, 2 running, 0 zombie, 4 stopped
CPU0 states: 0.0% user, 2.0% system, 0.0% nice, 97.0% idle
CPU1 states: 0.0% user, 0.1% system, 0.0% nice, 99.0% idle
CPU2 states: 79.0% user, 2.0% system, 0.0% nice, 17.0% idle
CPU3 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
CPU4 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
CPU5 states: 0.1% user, 0.1% system, 0.0% nice, 98.0% idle
CPU6 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
CPU7 states: 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
Mem: 3624156K av, 3526480K used, 97676K free, 0K shrd, 568K buff
Swap: 4192912K av, 89404K used, 4103508K free 3264864K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
6979 postgres 25 0 93364 91M 83464 R 81.8 2.5 26:18 postmaster
11164 postgres 16 0 1064 1064 840 R 2.9 0.0 0:00 top
19 root 15 0 0 0 0 SW 0.9 0.0 58:33 kswapd
7126 postgres 18 0 84604 82M 83420 D 0.9 2.3 1:58 postmaster
an explain of a simple query (couldn't vacuum this table, due to
this problem on the page header).
mis_logdata=# select count(*) from dat_cc_fail_auths;
ERROR: invalid page header in block 90259 of relation "dat_cc_fail_auths"
mis_logdata=# explain select count(*) from dat_cc_fail_auths;
QUERY PLAN
------------------------------------------------------------------------------------------
Aggregate (cost=100000022.50..100000022.50 rows=1 width=0)
-> Seq Scan on dat_cc_fail_auths (cost=100000000.00..100000020.00 rows=1000 width=0)
(2 rows)
mis_logdata=#
I've found a tool, pgfsck, but could not use it, the author forgot to upgrade the script to make it compatible with the actual postgres versions.
Other usefull tools?
Best wishes, and thanks in advance.
Guido.
From | Date | Subject | |
---|---|---|---|
Next Message | Matt | 2004-11-18 15:36:35 | Re: patch: plpgsql - access records with rec.(expr) |
Previous Message | James Robinson | 2004-11-18 14:36:01 | plpgsql on 8.0b4 bug? |