Re: checkpoint write errors ( getting worse )

CS DBA <cs_dba@xxxxxxxxxxxxxxxxxxx> · Sat, 22 Oct 2016 15:35:25 -0600



    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@xxxxxxxxxxxxxxxxxxx>
        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