Re: Detecting database corruption
От | Joshua D. Drake |
---|---|
Тема | Re: Detecting database corruption |
Дата | |
Msg-id | 400C3583.3020200@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Detecting database corruption (Jack Orenstein <jorenstein@reference-info.com>) |
Список | pgsql-general |
> Do you mean that this happens in a few select situations? Or that > there are configuration flags that can be used to enable such checks? > It is a few select situations and frankly I haven't had database corruption because of PostgreSQL since the 7.1 days. I have had however database corruption due to bad memory, and bad Linux kernels/filesystems. > >>- Are there any tools we can run to determine whether a database is > >>corrupt? Typically PostgreSQL will tell you via an error message pointing to a relation id. Also if you perform regular vacuums if vacuum fails it will typically tell you where. > > > The real question is, what have you been using that makes database > > corruption such a grave concern? If I had to worry that much about > > Postgres database corruption, I'd use something else. > > even if that means nothing beyond a clean shutdown of the > application. Second, we are struggling with the IDE vs. fsync issue, > that has come up on this mailing list. We definitely have to support > IDE drives, and we're trying to determine how to balance performance > against other concerns. If we do end up leaving IDE caching enabled, > then my understanding is that corruption is a real possibility, (or > have I drawn the wrong conclusion on this point?) > I think (at least personally) that you are placing a little too much emphasis on this problem. We have successfully done power plug tests over and over and over with IDE drives and not had the issue come about. Of course this entirely depends on many things, but that is what a UPS is for. Sincerely, Joshua D. Drake > Jack Orenstein > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
В списке pgsql-general по дате отправления: