Kevin Brown <kevin@sysexperts.com> writes:
> After examining the output of pg_filedump, it became obvious this was
> a corrupt page issue. What bothers me is the way in which it's
> corrupt. The corrupt data looks supiciously like the data from
> different table, or perhaps from an index. In this case, from the
> short_desc field of the bugs table, which has a datatype of 'text' (I
> presume this means it's TOASTed?). The text data in the corrupt page
> exactly matches entries in that field of the bugs table.
Substitution of a page from a different table seems unlikely to result
in this error, as the tuple header layout is the same for all tables.
A page from an index, though, maybe. Does the suspicious looking page
have any pd_special space?
We have in the past seen data-corruption errors that were clearly due to
substitution of a chunk of entirely non-Postgres data for a table page.
I suppose that those are symptoms of either kernel or device misfeasance
... it's hard to see how Postgres could cause that to happen. We've not
seen enough of them to detect any pattern though. I rather wonder if
what you've seen is the same thing but the substituted data happens to
be from another Postgres file.
> Additionally, if you'd like to see the output of pg_filedump, I'll be
> happy to post it here (or email it separately). I hesitate to attach
> it here because it's not clear the mailing list's spam filtering would
> let it pass.
You should at least show the page you think is corrupt.
regards, tom lane