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
later.
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
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
