Re: COMMIT NOWAIT Performance Option
От | Jonah H. Harris |
---|---|
Тема | Re: COMMIT NOWAIT Performance Option |
Дата | |
Msg-id | 36e682920702281110o287aae37i69d1e0bdfc97495f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: COMMIT NOWAIT Performance Option (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: COMMIT NOWAIT Performance Option
Re: COMMIT NOWAIT Performance Option Re: COMMIT NOWAIT Performance Option Re: COMMIT NOWAIT Performance Option |
Список | pgsql-hackers |
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. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: