| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Amiel <becauseimjeff(at)yahoo(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: drive failre, corrupt data... |
| Date: | 2007-01-18 23:43:42 |
| Message-ID: | 7884.1169163822@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Jeff Amiel <becauseimjeff(at)yahoo(dot)com> writes:
> ran fsck
> PARTIALLY TRUNCATED INODE I=612353
> SALVAGE? yes
> INCORRECT BLOCK COUNT I=612353 (544 should be 416)
> CORRECT? yes
> root(at)back-app-1# find /db -inum 612353
> /db/pg_clog/0952
Yech. So much for RAID reliability ... maybe you need to reconfigure
the array for more redundancy?
> So....am I screwed here...just I just re-init-db and restore the entire kit and kaboodle from scratch?
Given that it's just a backup machine, it's probably not worth heroics
to try to recover. I'm not sure that you could trust any data you got
out of it, anyway --- corrupted pg_clog is likely to lead to
inconsistency in the form of partially-applied transactions, which can
be hard to detect.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2007-01-18 23:52:21 | Re: PG not rejecting bad dates (was Re: Finding bogus dates) |
| Previous Message | Ron Johnson | 2007-01-18 23:42:54 | PG not rejecting bad dates (was Re: Finding bogus dates) |