On 2003-04-03 18:40:54 -0500, Tom Lane wrote:
> Vincent van Leeuwen <pgsql.spam@vinz.nl> writes:
> > ... This cost us about 10 hours downtime. If I'd had the option I just
> > would've set ZERO_DAMAGED_PAGES to true and let it run for a few days to sort
> > itself out.
>
> Yikes. If I understand this correctly, you had both critical data and
> cache data in the same database. As for the cache stuff, a few quick
> TRUNCATE TABLE commands would have gotten you out of the woods. As for
> the critical data (the stuff you actually needed to dump and restore),
> do you really want ZERO_DAMAGED_PAGES on for that? It's a heck of a
> blunt tool.
>
> regards, tom lane
No, it wasn't that bad :) The REAL data is on a different server which hasn't
let us down so far (and has reliable hardware and software, and backups :)).
Only the cache database was hurt. The problem with truncating everything was
that rebuilding the cache would cost about 48 hours downtime, as there is A
LOT of data to rebuild. This really is an interim solution, things will be
constructed much better and more reliable in the future, but for now it's
there.
Another reason we went for the dump/restore is that we upgraded to 7.3.2 at
the same time, which we were postponing because weren't looking forward to
that downtime :)
Vincent van Leeuwen
Media Design - http://www.mediadesign.nl/
