| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com> |
| Cc: | jd(at)commandprompt(dot)com, "Chen, Dongdong (GE Healthcare)" <DongdongChen(at)ge(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: need help for PostgreSQL consistency check mechanism |
| Date: | 2009-04-24 17:05:42 |
| Message-ID: | 20090424170542.GT10358@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Filip Rembiałkowski escribió:
> OTOH, there could be some consistency check method... If postgres had block-
> or row-level checksums, this could do.
Row level: it would be very expensive to compute, store and keep up to
date. And it doesn't protect you from corruption elsewhere in the
block.
Block level: there was some effort to implement it for 8.4, but it fell
into some deadly traps.
> The best way I know is to do plain pg_dumpall. But this does not detect all
> data corruptions.
I wrote some plpgsql code a month ago to scan a table and detoast all
toastable attributes, reporting it when an exception was raised. It was
a very effective way to detect corrupted toast entries, which is the
most visible way in which data is corrupted.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joao Ferreira gmail | 2009-04-24 17:24:34 | Re: Selling an 8.1 to 8.3 upgrade |
| Previous Message | Josh Trutwin | 2009-04-24 17:01:52 | Selling an 8.1 to 8.3 upgrade |