Re: COMMIT NOWAIT Performance Option - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: COMMIT NOWAIT Performance Option
Date
Msg-id 200702281912.l1SJCON22868@momjian.us
Whole thread Raw
In response to Re: COMMIT NOWAIT Performance Option  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Responses Re: COMMIT NOWAIT Performance Option  ("Jonah H. Harris" <jonah.harris@gmail.com>)
List pgsql-hackers
Jonah H. Harris wrote:
> On 2/28/07, Bruce Momjian <bruce@momjian.us> 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.
> 
> 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.
> 
> If consistency is stored at the block-level, which is pretty much the
> only way to avoid full page writes, you have to accept some level of
> possible corruption.

Am am not comfortable starting and having something fail later.  How
other databases do it is not an issue for me.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: "Jonah H. Harris"
Date:
Subject: Re: COMMIT NOWAIT Performance Option
Next
From: Oleg Bartunov
Date:
Subject: Re: SOC & user quotas