Re: Various serverlog messages

If an IDE drive has a bad block, doesn't it just mark the block as bad
and map in a new one, perhaps taking as much of the old block as it can?
Maybe that is the cause.

From my experience, SCSI reports a block error and will not read it.

---------------------------------------------------------------------------

Tom Lane wrote:
> CSN <cool_screen_name90001(at)yahoo(dot)com> writes:
> > Yes, pg_dump and pg_dumpall appear to work fine. The
> > output for all of the dbs (except one) for the select
> > above is:
> > [ normal looking ]
> > Here's the exception:
>
> > 16656 | pg_toast_16384_index | 99 | 0
> > | 1 | 403 | 3682590432 | 1 |
> > 0 | 0 | 0 | f | f
> > | i | 2 | 0 | 0
> > | 0 | 0 | 0 | f | f
> > | f | f |
> > (1 row)
>
> Sure enough, the relfilenode column (which determines the actual on-disk
> filename) is clobbered. Weird as can be ... could you have suffered a
> hardware glitch affecting just that one word? Doesn't seem real likely
> --- the glitches I've seen in the past tend to take out more than a word
> at a time. But it's not easy to credit as a software error either.
>
> You could fix this database with a quick UPDATE command to set
> relfilenode back to what it should be in this pg_class row. However,
> it'd be wise to wonder what other issues might be lurking. If I were
> you I'd do a pg_dumpall/initdb/reload cycle, and also spend some time on
> hardware testing (if you're on Intel hardware, memtest86 has a good
> reputation for finding RAM problems, and people have successfully found
> disk problems with badblocks).
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073