On 18 December 2012 02:21, Jeff Davis <pg...@j-davis.com> wrote: > On Mon, 2012-12-17 at 19:14 +0000, Simon Riggs wrote: >> We'll need a way of expressing some form of corruption tolerance. >> zero_damaged_pages is just insane, > > The main problem I see with zero_damaged_pages is that it could > potentially write out the zero page, thereby really losing your data if > it wasn't already lost. (Of course, we document that you should have a > backup first, but it's still dangerous). I assume that this is the same > problem you are talking about.
I think we should discuss whether we accept my premise? Checksums will actually detect more errors than we see now, and people will want to do something about that. Returning to backup is one way of handling it, but on a busy production system with pressure on, there is incentive to implement a workaround, not a fix. It's not an easy call to say "we've got 3 corrupt blocks, so I'm going to take the whole system offline while I restore from backup". If you do restore from backup, and the backup also contains the 3 corrupt blocks, what then? Clearly part of the response could involve pg_dump on the damaged structure, at some point. > I suppose we could have a new ReadBufferMaybe function that would only > be used by a sequential scan; and then just skip over the page if it's > corrupt, depending on a GUC. That would at least allow sequential scans > to (partially) work, which might be good enough for some data recovery > situations. If a catalog index is corrupted, that could just be rebuilt. > Haven't thought about the details, though. Not sure if you're being facetious here or not. Mild reworking of the logic for heap page access could cope with a NULL buffer response and subsequent looping, which would allow us to run pg_dump against a damaged table to allow data to be saved, keeping file intact for further analysis. I'm suggesting we work a little harder than "your block is corrupt" and give some thought to what the user will do next. Indexes are a good case, because we can/should report the block error, mark the index as invalid and then hint that it should be rebuilt. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
