> Joshua D. Drake wrote: > ... > ZFS is not an option; generally speaking.
Then in general, if the corruption occurred within the: - read path, try again and hope it takes care of itself. - write path, the best that can be hoped for is a single bit error within the data itself which can be both detected and corrected with a sufficiently strong check sum; or worst case if address or control information was corrupted, god knows what happed to the data, and what other data may have been destroyed by having the data written to the wrong blocks and typically unrecoverable. - drive itself, this is most typically very unlikely, as strong FEC codes typically prevent the misidentification of unrecoverable data as being otherwise. The simplest thing to do would seem to be to upon reading blocks check the check sum, if bad, try read again; if that doesn't fix the problem, assume a single bit error, and iteratively flip single bits until the check sum matches (hopefully not making the problem worse as may be the case if many bits were actually already in error) and write the data back, and proceed as normal, possibly logging the action; otherwise presume the data is unrecoverable and in error, somehow mark it as being so such that subsequent queries which may utilize any portion of it knows it may be corrupt (which I suspect may be best done not on file-system blocks, but actually on a logical rows or even individual entries if very large, as my best initial guess, and likely to measurably affect performance when enabled, and haven't a clue how resulting query should/could be identified as being potentially corrupt without confusing the client which requested it). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
