Thread: could not read block... how could I identify/fix
There was a hardware crash.
Since then INSERT to one table is failing with the following message:
ERROR: could not read block 11857 of relation base/16396/3720450: read only 0 of 8192 bytes
ERROR: could not read block 11805 of relation base/16396/3720450: read only 0 of 8192 bytes
Similar error was fixed by doing re-indexing or identifying corrupted data by COPY command and remove the row etc.
However, the issue hasn't been resolved yet after taking the following actions:
REINDEXed entire table. It was successful.
pg_dump was also successful then restore was successful.
COPY corrupted table to file was successful with no error.
Analyze was also successful with no error.
Do you think this should be the next step I might take?
Could you give me an advice of how I could identify corrupted error.
Version: "PostgreSQL 8.4.6 on i386-apple-darwin, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370), 32-bit"
Thank you very much for your time in advance.
------
Naoko
Since then INSERT to one table is failing with the following message:
ERROR: could not read block 11857 of relation base/16396/3720450: read only 0 of 8192 bytes
ERROR: could not read block 11805 of relation base/16396/3720450: read only 0 of 8192 bytes
Similar error was fixed by doing re-indexing or identifying corrupted data by COPY command and remove the row etc.
However, the issue hasn't been resolved yet after taking the following actions:
REINDEXed entire table. It was successful.
pg_dump was also successful then restore was successful.
COPY corrupted table to file was successful with no error.
Analyze was also successful with no error.
Do you think this should be the next step I might take?
Could you give me an advice of how I could identify corrupted error.
Version: "PostgreSQL 8.4.6 on i386-apple-darwin, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370), 32-bit"
Thank you very much for your time in advance.
------
Naoko
On Wed, Mar 28, 2012 at 6:31 PM, Naoko Reeves <naokoreeves@gmail.com> wrote: > Do you think this should be the next step I might take? > Could you give me an advice of how I could identify corrupted error. It seems to me that since you can successfully dump the table (I assume you validated the data was all there somehow), you should go ahead and dump your whole DB, delete the current one, create it again, then restore it from scratch.
On Wed, Mar 28, 2012 at 6:31 PM, Naoko Reeves <naokoreeves@gmail.com> wrote: > Version: "PostgreSQL 8.4.6 on Oh, and also upgrade to 8.4.11 to ensure you do not have any known data loss bugs.
Vick,
Thank you very much. Yes, I just go ahead did what you said and all appears to be fine.
--
Naoko Reeves
Thank you very much. Yes, I just go ahead did what you said and all appears to be fine.
On Thu, Mar 29, 2012 at 7:08 AM, Vick Khera <vivek@khera.org> wrote:
On Wed, Mar 28, 2012 at 6:31 PM, Naoko Reeves <naokoreeves@gmail.com> wrote:It seems to me that since you can successfully dump the table (I
> Do you think this should be the next step I might take?
> Could you give me an advice of how I could identify corrupted error.
assume you validated the data was all there somehow), you should go
ahead and dump your whole DB, delete the current one, create it again,
then restore it from scratch.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Naoko Reeves
On Thu, Mar 29, 2012 at 7:47 PM, Naoko Reeves <naokoreeves@gmail.com> wrote: > Vick, > Thank you very much. Yes, I just go ahead did what you said and all appears > to be fine. You definitely need to check your hardware for faults, especially the one that caused your server to crash. Run some memory tests, drive tests etc.