> 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