Skip site navigation (1) Skip section navigation (2)

Re: could not read block 77 of relation 1663/16385/388818775

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Marc Schablewski <ms(at)clickware(dot)de>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: could not read block 77 of relation 1663/16385/388818775
Date: 2008-11-27 10:22:08
Message-ID: 492E74D0.90501@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

pgsql-bugs by date

Next:From: SushilDate: 2008-11-27 12:27:34
Subject: Re: executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error
Previous:From: Marc SchablewskiDate: 2008-11-27 09:49:57
Subject: Re: could not read block 77 of relation 1663/16385/388818775

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group