So I ran REINDEX on all the db's and the errors went away for a bit. Now I'm seeing this:
Log entries like this:FATAL: could not read block 0 of relation base/1311892067/2687: read only 0 of 8192 bytes
So I checked which db it is:
$ psql -h localhost
psql (8.4.20)
Type "help" for help.
postgres=# select datname from pg_database where oid = 1311892067;
datname
---------
access_one
(1 row)
But when I attempt to connect to the db so I can query for the table in pg_class I get this:
postgres=# \c access_one
FATAL: could not read block 0 of relation base/1311892067/2687: read only 0 of 8192 bytes
Thoughts?
On 10/22/2016 07:52 AM, CS DBA wrote:
Thanks the REINDEX fixed it, it's a client of ours and we're pushing to get them to move to 9.5
On 10/21/2016 06:33 PM, Tom Lane wrote:
CS DBA <cs_dba@consistentstate.com> writes:
we're seeing the below errors over and over in the logs of one of our
postgres databases. Version 8.4.22
[ you really oughta get off 8.4, but you knew that right? ]
Anyone have any thoughts on correcting/debugging it?
ERROR: xlog flush request 2571/9C141530 is not satisfied --- flushed
only to 2570/DE61C290
CONTEXT: writing block 4874 of relation base/1029860192/1029863651
WARNING: could not write block 4874 of base/1029860192/1029863651
DETAIL: Multiple failures --- write error might be permanent.
Evidently the LSN in this block is wrong. If it's an index, your idea of
REINDEX is probably the best solution. If it's a heap block, you could
probably make the problem go away by performing an update that changes any
tuple in this block. It doesn't even need to be a committed update; that
is, you could update or delete any row in that block, then roll back the
transaction, and it'd still be fixed.
Try to avoid shutting down the DB until you've fixed the problem,
else you're looking at replay from whenever the last successful
checkpoint was :-(
Maybe I need to run a REINDEX on whatever table equates to
"base/1029860192/1029863651"? If so how do I determine the db and table
for "base/1029860192/1029863651"?
1029860192 is the OID of the database's pg_database row.
1029863651 is the relfilenode in the relation's pg_class row.
regards, tom lane