>
> > By the way, may I ask more question regarding Oracle? You mentioned
> > the magic of no-fsync in Oracle is actually a bug. Ok, I understand. I
> > also heard that Oracle does some kind of redo-log bufferings. Does
> > this mean certain committed data might be lost if the system crashed
> > before the buffered data is written into the disk?
>
> That is my guess. Informix does that. No run runs with non-buffered
> logging. They run with buffered logging, which may loose transactions
> for a few seconds or minutes before a crash.
>
> I think we need that, and it should be the default, but few people agree
> with me. I have some schemes to do this.
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.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #