Re: Corrupted data, best course of repair?

> They run with fsync off AND they like to toggle the power switch at
> random? I'd suggest finding other employment --- they couldn't
> possibly be paying you enough to justify cleaning up after stupidity
> as gross as that.

Colo-by-windows. If there weren't DBAs with Win32 admin tendencies,
I'd be out of work. :)

> Anyway, the errors appear to indicate that there are pages in the
> database with LSN (last WAL location) larger than the actual current
> end of WAL. The difference is pretty large though --- at least 85MB
> of WAL seems to have gone missing. My first thought was a corrupted
> LSN field. But seeing that there are at least two such pages, and
> given the antics you describe above, what seems more likely is that
> the LSNs were correct when written. I think some page of WAL never
> made it to disk during a period of heavy updates that was terminated
> by a power cycle, and during replay we stopped at the first point
> where the WAL data was detectably corrupt, and so a big chunk of WAL
> never got replayed. Which of course means there's probably a lot of
> stuff that needs to be fixed and did not get fixed, but in
> particular our idea of the current end-of-WAL address is a lot less
> than it should be. If you have the server log from just after the
> last postmaster restart, looking at what terminated the replay might
> confirm this.

Peachy.

> You could get the DB to stop complaining by doing a pg_resetxlog to
> push the WAL start address above the largest "flush request"
> mentioned in any of the messages. But my guess is that you'll find
> a lot of internal corruption after you do it. Going back to the
> dump might be a saner way to proceed.

Tons of corruption and a backup that's a few weeks old. *grin* The
most recent dump seems to have all of the data, but some rows are
there in duplicate. Thanks for the input. -sc

--
Sean Chittenden