| From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> | 
|---|---|
| To: | Leif Biberg Kristensen <leif(at)solumslekt(dot)org> | 
| Cc: | pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: I/O error on data file, can't run backup | 
| Date: | 2011-10-06 05:07:11 | 
| Message-ID: | 4E8D377F.3070206@ringerc.id.au | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
On 10/06/2011 03:06 AM, Leif Biberg Kristensen wrote:
> I seemingly fixed the problem by stopping postgres and doing:
>
> balapapa 612249 # mv 11658 11658.old
> balapapa 612249 # mv 11658.old 11658
>
> And the backup magically works.
Woooooo! That's ... "interesting".
I'd be inclined to suspect filesystem corruption, a file system bug / 
kernel bug (not very likely if you're on ext3), flakey RAM, etc rather 
than a failing disk ... though a failing disk _could_ still be the culprit.
Use smartmontools to do a self-test; if 'smartctl -d ata -t long 
/dev/sdx' (where 'x' is the drive node) is reported by 'smartctl -d ata 
-a /dev/sdx' as having passed, there are no pending or uncorrectable 
sectors, and the disk status is reported as 'HEALTHY' your disk is quite 
likely OK. Note that a 'PASSED' or 'HEALTHY' report by its self doesn't 
mean much, disk firmwares often return HEALTHY even when the disk can't 
even read sector 0.
I strongly recommend making a full backup, both a pg_dump *and* a 
file-system level copy of the datadir. Personally I'd then do a test 
restore of the pg_dump backup on a separate Pg instance and if it looked 
OK I'd re-initdb then reload from the dump.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Buckley | 2011-10-06 05:47:29 | user-interface to upload csv files | 
| Previous Message | khizer | 2011-10-06 04:41:39 | Fwd: Postgresql-8.2 Replication |