Marc Schablewski wrote:
> If pages with bogus data but correct checksum are
> ever found on disk, I think this would prove that there is no hardware /
> file system / os issue.
No, it would only suggest that the issue is not in the filesystem or I/O
subsystem. Even then, it wouldn't catch bugs where the contents of one
block are copied over or swapped with another block. The checksum would
be calculated when a page is written to disk, so the corruption could
still be caused by faulty memory, memory bus, CPU or OS, while the page
sits in the buffer cache.
> If an access violation resulting from writes to locked pages were hit,
> would it be possible to log a stack backtrace?
I think you'd get a segmentation fault. With a core dump if the system
is configured so.
> Question: Who is responsible for maintaining this part (buffer cache
> maintenance, writer etc) of postgres code?
There's no named individuals, just the community in general.
In response to
pgsql-bugs by date
|Next:||From: Sushil||Date: 2008-11-27 12:27:34|
|Subject: Re: executing SELECT xmlelement(name foo); causes "server
closed the connection unexpectedly" Error|
|Previous:||From: Marc Schablewski||Date: 2008-11-27 09:49:57|
|Subject: Re: could not read block 77 of relation 1663/16385/388818775|