Merlin Moncure <mmoncure@xxxxxxxxx> writes: > On Mon, Jul 25, 2011 at 3:05 PM, Mcleod, John <johnm@xxxxxxxxxxxxxxx> wrote: >> I'm receiving the following error >> CONTEXT: writing block 614 of relation 394198/412175 >> WARNING: could not write block 614 of 394198/412175 >> DETAIL: Multiple failures --- write error may be permanent. >> ERROR: xlog flush request 0/34D53680 is not satisfied --- flushed only to >> 0/34CD1EB0 > This is a fairly low level error that is telling you the WAL could not > be written out. Out of drive space? Data corruption? Yeah, this looks like the detritus of some previous failure. There are basically two possibilities: 1. The problem page's LSN field has gotten trashed so that it appears to be past the end of WAL. 2. The page actually did get updated by a WAL entry with that LSN, and then there was a crash for some reason, and the database tried to recover by replaying WAL, and it hit some problem that caused it to stop recovering before what had really been the end of WAL. So now it thinks the end of WAL is 0/34CD1EB0, but there are page(s) out there with LSNs past that, and when it finds one you start getting complaints like this. I doubt theory #1, though, because there are nearby fields in a page header that evidently weren't trashed or else the page would have been recognized as being corrupt. Also the reported LSN is not very far past end of WAL, which would be unlikely in the event of random corruption. So I'm betting on #2. Unfortunately this tells us little about either the cause of the original crash, or the reason why recovery didn't work properly. We'd need a lot more information before speculating about that, for starters the exact Postgres version and the platform it's running on. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
