Re: Proposal: Integrity check

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> Tom Lane wrote:
>>> This seems like a pretty horrid idea. Bad pages shouldn't be allowed to
>>> get into shared buffers in the first place. Why not have the checking
>>> logic operate outside shared buffers?
>
>> It currently works outside the shared buffers, but I afraid about
>> collision due to parallel read and write access on one block. I'm not
>> sure if parallel write(8k) and read(8k) is synchronized by kernel/fs or
>> not. If not it should generates false positive results. If yes than I'm
>> happy :-) with outside processing.
>
> We're already assuming that; otherwise base backups for PITR don't work.

Don't full page writes protect us? I thought you had to start applying logs
forward from the point the backup started. Should we be forcing full page
writes during the base backup, perhaps treating the start of the base backup
as if it was a checkpoint as far as triggering full page writes?

I have little confidence that write(2) and read(2) calls are synchronized in
this manner when postgres's page size is larger than the filesystem block
size. Certainly I doubt someone issuing a write(2) of a few megabytes is going
to stop another process from being able to issue reads against the same file
until those megabytes are all in kernel cache, let alone if they overflow
cache and force i/o.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!