On Wednesday, December 23, 2015 6:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Paul Jones <pbj@cmicdo.com> writes:
> > I have been having disk errors that have corrupted something in
> > my postgres database. Other databases work ok:
>
> > postgres=# SELECT pg_catalog.pg_is_in_recovery();
> > ERROR: could not read block 3 in file "base/12511/12270": read only 4096 of 8192 bytes
>
> Hm. Evidently you've got a partially truncated file for some system
> catalog or index. It's fairly hard to estimate the consequences of
> that without knowing which one it is. Please see if this works:
>
> $ export PGOPTIONS="-c ignore_system_indexes=true"
> $ psql -U postgres
>
> # show ignore_system_indexes;
> (should say "on")
>
> # select relname, relkind from pg_class where pg_relation_filenode(oid) = 12270;
paul@kitanglad:~$ export PGOPTIONS="-c ignore_system_indexes=true"
paul@kitanglad:~$ psql -U postgres
psql (9.4.5)
Type "help" for help.
postgres=# show ignore_system_indexes;
ignore_system_indexes
-----------------------
on
(1 row)
postgres=# select relname, relkind from pg_class where pg_relation_filenode(oid) = 12270;
relname | relkind
-------------------+---------
pg_proc_oid_index | i
(1 row)
postgres=# reindex index pg_proc_oid_index;
REINDEX
postgres=# \q
paul@kitanglad:~$ unset PGOPTIONS
paul@kitanglad:~$ psql -U postgres
psql (9.4.5)
Type "help" for help.
postgres=# SELECT pg_catalog.pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)
So, it was an index and was quickly fixed.
Thanks!
>
>
> If that works, and it tells you filenode 12270 is an index, you're in
> luck: just REINDEX that index and you're done (at least with this problem,
> there might be more lurking behind it). Don't forget to unset PGOPTIONS
> afterwards.
>
>
> > Since this is the "postgres" database, dropping and re-creating it
> > doesn't seem possible.
>
> Sure it is, as long as you issue the commands from a non-broken database:
>
> # drop database postgres;
> DROP DATABASE
> # create database postgres with template template0;
> CREATE DATABASE
>
> If you don't have any custom objects in the postgres database, this would
> be by far the easiest way out.
Good to know! I thought there was something special about "postgres".
I have not modified it from what initdb put there.
>
> regards, tom lane
