Re: checkpoint write errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: CS DBA <cs_dba(at)consistentstate(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: checkpoint write errors
Date: 2016-10-22 00:33:17
Message-ID: 1613.1477096397@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

CS DBA <cs_dba(at)consistentstate(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2016-10-22 07:04:15 Re: Replication rolling back to normal.
Previous Message Vick Khera 2016-10-21 21:02:01 Re: Large empty table, balanced INSERTs and DELETEs, not being vacuumed