Andrew Sullivan <[EMAIL PROTECTED]> writes:
> You know you have big-trouble, oh-no, ISP ran over
> the tapes while they were busy pitching magnets through your cage,
> data corruption problems, and this is your best hope for recovery?
> Great. Log in, turn on this option, and start working. But across
> every back end? It's the doomsday device for databases.
Yeah, it is. Actually, the big problem with it in my mind is this
scenario: you get a page-header-corrupted error on page X, you
investigate and decide there's no hope for page X, so you turn on
zero_damaged_pages and try to dump the table. It comes to page X,
complains, zeroes it, proceeds, ... and then comes to damaged page Y,
complains, zeroes it, proceeds. Maybe you didn't know page Y had
problems. Maybe you could have gotten something useful out of page Y
if you'd looked first. Too late now.
What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting,
but an explicit command to "DESTROY PAGE n OF TABLE foo". That would
make you manually admit defeat for each individual page before it'd
drop data. But I don't presently have time to implement such a command
(any volunteers out there?). Also, I could see where try-to-dump, fail,
DESTROY, try again, lather, rinse, repeat, could get pretty tedious on a
badly damaged table.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
