From: | Emmanuel Cecchet <manu(at)frogthinker(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Durability? |
Date: | 2009-08-07 21:08:17 |
Message-ID: | 4A7C97C1.1040108@frogthinker.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Emmanuel Cecchet <manu(at)frogthinker(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-08-07 21:17:42 | Re: docs: mention autovacuum when ANALYZE is recommended |
Previous Message | Tom Lane | 2009-08-07 20:30:23 | Re: Review: Revise parallel pg_restore's scheduling heuristic |