Tom Lane wrote: > 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.
Can we make the GUC setting a numeric, so you can set it to 1 and it clears just one page, or 0 and it clears all pages? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
