On Tue, Dec 18, 2012 at 04:06:02AM -0500, Greg Smith wrote: > On 12/18/12 3:17 AM, Simon Riggs wrote: > >Clearly part of the response could involve pg_dump on the damaged > >structure, at some point. > > This is the main thing I wanted to try out more, once I have a > decent corruption generation tool. If you've corrupted a single > record but can still pg_dump the remainder, that seems the best we > can do to help people recover from that. Providing some > documentation on how to figure out what rows are in that block, > presumably by using the contrib inspection tools, would be helpful > too.
FWIW, Postgres is pretty resiliant against corruption. I've maintained a postgres db on a server with bad memory (don't ask) and since most scrambling was in text strings you just got funny output sometimes. The most common failure was a memory allocation failure as postgres tried to copy a datum whose length field was correupted. If things went really wonky you could identify the bad tuples by hand and then delete them by ctid. Regular reindexing helped too. All I'm saying is that a mode where you log a warning but proceed anyway is useful. It won't pin down the exact error, but it will tell you where to look and help find the non-obvious corruption (so you can possibly fix it by hand). Have a nice day, -- Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
signature.asc
Description: Digital signature
