Re: Durability? - Mailing list pgsql-hackers

From Emmanuel Cecchet
Subject Re: Durability?
Date
Msg-id 4A7C97C1.1040108@frogthinker.org
Whole thread Raw
In response to Re: Durability?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Durability?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Emmanuel Cecchet <manu@frogthinker.org> writes:
>   
>> I got an error like this:
>>     
>
>   
>> ERROR:  xlog flush request 1/C121E998 is not satisfied --- flushed only to 1/BCBCB440
>> CONTEXT:  writing block 529 of relation 1663/233690/1247
>> WARNING:  could not write block 529 of 1663/233690/1247
>> DETAIL:  Multiple failures --- write error might be permanent.
>>     
>
>   
>> The xrecoff value (logs show 1/xrecoff) advances a few times during the day, but the message keeps appearing.
>>     
>
> It looks like you've got a corrupted page in shared buffers, and every
> time the system tries to flush it to disk for a checkpoint, it fails.
>
> What I'd try for getting out this is to kill -9 some backend in order
> to force a database restart.  Of course, if you want to investigate
> what caused it, you should dig around in shared memory first and try
> to get a copy of that buffer's contents.
>   
Will the database be able to restart with a corrupted WAL?
If the database restarts, what transactions will be missing:
- just the block that couldn't be flushed?
- all transactions that were committed after the faulty block?
- more?

Thanks
Emmanuel


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Next
From: Alvaro Herrera
Date:
Subject: Re: docs: mention autovacuum when ANALYZE is recommended