Subject: How does POSTGRES handle crash recovery ?

From: Niranjan Perera <[email-masked]>
Date: Tue, 7 Jun 1994 11:01:25 -0400 (EDT)

I would like to know how POSTGRES handles "crash recovery".

Thanks,

-- Niranjan
-- 
+----------------------------------------------------------------?------+
| Niranjan Perera, 415 GSRC Bldg,CS Dept,  [email-masked]    ~~~     |
| University Of Georgia,  Athens GA30602.  (706)-548-5826     ( . . )   |
+-----------------------------------------------------------ooO-(_)-Ooo-+

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "[email-masked]"

   If this fails, send mail to "[email-masked]" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================

---

From: [email-masked] (Paul M. Aoki)
Date: Thu, 09 Jun 94 15:43:49 -0700

> I would like to know how POSTGRES handles "crash recovery".

somebody else writes in private email:

   Consult the $POSTGRESDIR/doc/papers directory for a paper on the
   novel implementation of crash recovery in a PG database. 
 
   Basicly, there is no WAL (Write Ahead Log) and no undo or redo
   recovery. Each write is a distinct tuple in the relation, and
   the oid keeps track of updates. Selects can then be 'time restricted'
   because the entire history of the relation is stored in the 
   relation. Several relations; pg_log, pg_time etc, maintain logs
   of open transactions. If the machine crashes, you simply start it
   up again. Any uncommited transactions are not noted in the log
   and hence simply aren't there, so far as PG is concerned.
 
   This gives you, effectively, instant re-start. 
 
   This is gone into in mush more detail in the docs noted above . . .

one plus of the postgres storage manager is the "instant crash
recovery."  one minus is that it does not address media failure (e.g.,
bad sectors).  the stock answer to the media failure problem is to
throw hardware at it (e.g., use raid -- mirrored files, ecc,
whatever).  frequent (offline) backups are recommended in the new
documentation.  ("backup frequently" is always safe DBA advice, i
suppose..)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki