From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adam Witney <awitney(at)sgul(dot)ac(dot)uk> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: "invalid page header in block 597621 of relation..."error |
Date: | 2005-11-23 21:36:42 |
Message-ID: | 27104.1132781802@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adam Witney <awitney(at)sgul(dot)ac(dot)uk> writes:
> Thanks for the help.... Here is the output:
> adam(at)bugsdb:/opt$ dd bs=8k skip=73333 count=1 if=134401991.4 | od -x
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0010000 1d9e 201c 0fa0 0000 0010 0000 0000 000b
> 0010020 0ca6 19fb 1797 0ab4 000a 0000 0000 0001
> 0010040 01af 0000 000a 0000 0000 0001 0ca7 0000
> 0010060 0012 0000 0000 0010 0002 1190 068f 0c9a
> ...
> Unfortunately I have no idea what any of that means!
The second half of the page looks reasonable, but the first half
is all zeroes :-(. (dd uses "*" to mean "same as above".)
It's unlikely that this is Postgres' fault; I can't think of any
plausible pathology within PG that would so carefully zero out just
half of a page. What seems more likely is that the block size on the
underlying filesystem is 4K, and that either a kernel bug or a disk
drive error has caused the system to drop the contents of one block.
If I had to bet with no additional info, I'd bet on kernel bug. What's
the platform exactly, and what filesystem are you using?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Witney | 2005-11-23 21:40:35 | Re: "invalid page header in block 597621 of relation..."error |
Previous Message | Adam Witney | 2005-11-23 21:23:15 | Re: "invalid page header in block 597621 of relation..."error |