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 expla
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 doe
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:
https://gazebo.sysexperts.com/~
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.
--
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 c
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
". I tracked it down vi
