Обсуждение: Best way to recover from crash?

Immediately after finally deploying our PG database up
on our mountain-top observatory, we got hit by lightening.
(The machines were *supposed* to be installed on a RUPS,
but weren't.  Sigh)

A file was lost.  Now many simple commands cause the
DB to 'crash':
----------------------------------------------------
lab.devel.configdb=# vacuum;
NOTICE:  Rel attributes_table: Uninitialized page 60523 - fixing
NOTICE:  Rel attributes_table: Uninitialized page 60524 - fixing
NOTICE:  Rel attributes_table: Uninitialized page 60525 - fixing
NOTICE:  Rel attributes_table: Uninitialized page 60526 - fixing
FATAL 2:  open of /var/lib/pgsql/data/pg_clog/0000 failed: No such file
or directory
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: NOTICE:
Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend
        died abnormally and possibly corrupted shared memory.
        I have rolled back the current transaction and am
        going to terminate your database system connection and exit.
        Please reconnect to the database system and repeat your query.
Failed.
!# \q
----------------------------------------------

I do nightly backups of the DBs so aside from observing time
lost this isn't catestrophic, but since it takes so long to
restore from backup (some of the DBs are fairly large) I was
wondering if there's a 'known procedure' for quickly recovering
from the above.

Thanks!
Steve
--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

Steve Wampler <swampler@noao.edu> writes:
> Immediately after finally deploying our PG database up
> on our mountain-top observatory, we got hit by lightening.
> (The machines were *supposed* to be installed on a RUPS,
> but weren't.  Sigh)

> A file was lost.  Now many simple commands cause the
> DB to 'crash':

> I do nightly backups of the DBs so aside from observing time
> lost this isn't catestrophic, but since it takes so long to
> restore from backup (some of the DBs are fairly large) I was
> wondering if there's a 'known procedure' for quickly recovering
> from the above.

I think you'd be foolish not to initdb and reload from the backups.
You have no way to know how extensive the data damage is ... you might
work around the problems you see now, only to find something else
later after you've put more data into the corrupted DB.

            regards, tom lane

On Thu, 2004-07-22 at 10:59, Tom Lane wrote:

> I think you'd be foolish not to initdb and reload from the backups.
> You have no way to know how extensive the data damage is ... you might
> work around the problems you see now, only to find something else
> later after you've put more data into the corrupted DB.

Thanks, Tom.  I did that and what you say makes sense.  I was
just overly worried about the down time since the backup database
dump was well over 4GB and looking for a quick fix.  On the
other hand, a 1-hour downtime (what it took) isn't so bad,
and knowing things are solid is worth more than that!

Thanks again,
Steve
--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.