JEANARTHUR@EUROVOX.FR writes:
> We just had a problem on the hard disk we resolved with fsck.
> Database server runs, queries on the DB seems ok, but when we do a
> vacuum (full or not), we have after some tables were vaccumed :
> mai 2 11:49:34 aphrodite logger: PANIC: XLogFlush: request
> 635F6373/6B636568 is not satisfied --- flushed only to 14/F9473CF4
Hm... I can't see how vacuum could get to that state --- XLogFlush
failure within vacuum should only be an ERROR not PANIC. I wonder
whether that was actually coming from a background checkpoint process?
(checkpoint shouldn't be PANICing either, but it looks like it would
at the moment :-()
But I digress. Your problem is evidently that you've got clobbered
table data. XLogFlush is unhappy because the first eight bytes of some
page have been overwritten with junk (text, it looks like: in ASCII that
value works out as "sc_check" ...). Whatever that page is, it's toast
now, but your problem is to identify it --- if you're really lucky it's
in an index or some other noncritical file.
You might try writing a little script in perl or some such to grovel
through all the database files looking for 8K pages that don't start
with small integers --- 00000000 to 00000014 are evidently the only
valid values. There could be more than one trashed page, but hopefully
there aren't many. Once you know the filenames containing the trashed
pages, see contrib/oid2name to identify what tables they are, and then
report back and we can give you advice about how to recover. You'll
probably end up zeroing out the trashed pages, but the first problem
is to know where they are.
regards, tom lane