Re: [HACKERS] Priorities for 6.6

>     The  major problem in this area is, that with the given model
>     of telling which tuples are committed, noone can guarantee  a
>     consistent  PostgreSQL  database in the case of a non-fsynced
>     crash.  You might  loose  some  tuples  and  might  get  some
>     outdated  ones back.  But it depends on subsequently executed
>     SELECT's which ones and it all doesn't have  anything  to  do
>     with  transaction  boundaries  or  with  the  order  in which
>     transactions committed.
> 
>     As I understand Oracle the entire reliability depends on  the
>     redo  logs.  If a crash is too badly, you can allways restore
>     the last backup and recover from that.   The  database  crash
>     recovery  will roll forward until the last COMMIT that occurs
>     in the redolog (except for point in time recovery).
> 
>     Someone can live  with  the  case,  that  the  last  COMMIT's
>     (sorted  by  time)  cannot  get recovered. But noone can live
>     with a database that's left corrupt.

Yes, I 100% agree.  We have to bring the database back to a consistent
case where only the last few transactions are not done at all, and all
previous ones are completely done.  See previous post on methods and
issues.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026