Kevin Brown [EMAIL PROTECTED] writes:
I'll put the files on a web server and post links to them here.
You can find them here:
https://gazebo.sysexperts.com/~kevin/postgresql
AFAICT, the first half of page 73 is OK, but the second half clearly is
trashed. In the raw-format dump it does
Tom Lane wrote:
It's fairly hard to see how that could happen inside Postgres. One can
readily imagine bugs that might replace one whole page with another,
but there aren't any operations that manipulate half-a-page. On the
other hand, if your kernel uses 4K blocksize, this could be
Tom Lane wrote:
You should at least show the page you think is corrupt.
I attempted to send this additional info to the list but I think the
message got dropped on the floor by the mailing list software or by
the spam filter.
I'll put the files on a web server and post links to them here.
--
I wrote:
I attempted to send this additional info to the list but I think the
message got dropped on the floor by the mailing list software or by
the spam filter.
I'll put the files on a web server and post links to them here.
You can find them here:
Apologies if my previous attempts to post this to the mailing list
have actually succeeded, but I've seen no evidence of that...
While doing some bugzilla testing, I ran into a data page corruption
issue.
The symptom was the usual could not access status of transaction
bignum. I tracked it
Kevin Brown [EMAIL PROTECTED] 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,
Hi List
Out of some reason our data of our postgresql database has been corrupted. When we try
to connect to the database we get:
psql: ERROR: _mdfd_getrelnfd: cannot open relation pg_type_oid_index:
No such file or directory
REINDEX does not work. We get the same error.
pgfsck gives us:
