From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Deniz Atak <denizatak(at)gmail(dot)com> |
Cc: | D M <dm(dot)aeqa(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success |
Date: | 2011-08-01 14:30:35 |
Message-ID: | 23420.1312209035@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Deniz Atak <denizatak(at)gmail(dot)com> writes:
> thanks for your answer. Do you have any opinion about how can I find the
> corrupted rows? Do you know how to read:
> "could not read block 4707 of relation 1663/16384/16564"
You should read the chapter about Database Physical Storage in the
manual to find out how to interpret that as a reference to a specific
block of an operating system file.
In this case, since we believe the problem is a partial block at end of
file, the file size presumably is more than 4707*8K and less than
4708*8K. If I had to recover from this I would physically truncate the
file to exactly 4707*8K bytes, after saving a copy of the remaining
bytes to see if there's anything useful in there. (Most likely there's
not --- in particular, if this is the after-effects of an
out-of-disk-space condition that prevented Postgres from filling up a
whole new block, then I'd expect the partial page to be filled with
zeroes.)
On Unix machines you could use dd for that, though I'd strongly
recommend practicing on a scratch file as it's not exactly user
friendly. Dunno what to use on Windows.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-08-01 14:30:41 | Re: Error: operator does not exist: integer = integer |
Previous Message | Tomas Vondra | 2011-08-01 14:25:46 | Re: ERROR: could not read block 4707 of relation 1663/16384/16564: Success |