Postgres Pro
Downloads
Home   >   mailing lists

Thread: cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error

cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error

From
"Andrew Bartley"
Date:
Hi,
 
We are using Postgres 7.1.3.
 
I run a nightly cron that drops all of the application table indexes then unload and reload the most heavily used tables to ensure they are in key sequence, then vacuum analyse the whole DB, recreate the indexes and triggers.
 
Over the weekend, this error appeared.
 
ERROR:  cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error
vacuumdb: vacuum  evolvo failed
 
Could this be a physical I/O error?
 
Can someone tell me what I can do to fix this?
 
Thanks
 
Andrew Bartley.

Re: cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error

From
Doug McNaught
Date:
"Andrew Bartley" <abartley@evolvosystems.com> writes:

> I run a nightly cron that drops all of the application table indexes
> then unload and reload the most heavily used tables to ensure they
> are in key sequence, then vacuum analyse the whole DB, recreate the
> indexes and triggers.
>
> Over the weekend, this error appeared.
>
> ERROR: cannot read block 39 of pg_attribute_relid_attnam_index:
> Input/output error vacuumdb: vacuum evolvo failed
>
> Could this be a physical I/O error?

Most likely yes.  Check your syslogs for kernel i/o error messages.

-Doug
--
Doug McNaught       Wireboard Industries      http://www.wireboard.com/

      Custom software development, systems and network consulting.
      Java PostgreSQL Enhydra Python Zope Perl Apache Linux BSD...

Re: cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error

From
Tom Lane
Date:
"Andrew Bartley" <abartley@evolvosystems.com> writes:
> ERROR:  cannot read block 39 of pg_attribute_relid_attnam_index: Input/outp=
> ut error

> Could this be a physical I/O error?

Sure looks like it.

> Can someone tell me what I can do to fix this?

If it's only the index that is hosed, and not any of the tables,
REINDEX should save the day.  See
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/sql-reindex.html

(Even though you're running 7.1, I recommend looking at the 7.2 docs in
this connection --- they're much more complete about how to use
REINDEX.)

            regards, tom lane