Jonah H. Harris wrote:
On 2/28/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> But if the system was shut down uncleanly as the result of a Postgres crash or > fast shutdown of Postgres then that isn't an issue. And many users may prefer > to bring the system up as soon as possible as long as they know any corrupt
> pages will be spotted and throw errors as soon as it's seen.

I don't think we should start up a system and only detect the errors

Which is, of course, how everyone else does it.  On block access, the
checksum is verified (if you've turned checksum checking on).  I
*really* doubt you want to pull in every page in the database at
startup time to verify the checksum or sequence.  Even pages from the
last checkpoint would be a killer.

AFAICS pages from the last checkpoint would be sufficient, and not that expensive given that we have to pull all the pages touched since last checkpoint from disk to do the WAL replay anyway.

All of the databases (Oracle, SQL Server, DB2) have a way to perform a
database corruption check which does go out and verify all checksums.

I think that's to protect from random disk errors rather than just torn pages. Which might be a useful thing but I think that level of protection belongs to the filesystem or storage hardware.

What's the use case for the torn-page detection, anyway? If you don't trust your OS/hardware to protect you from torn-pages, but you do care about your data, surely you would use full_pages_writes = on. If you do trust your OS/hardware, just turn it off. And if you don't care about your data, what's the point?

  Heikki Linnakangas

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to