Re: [HACKERS] Priorities for 6.6

>
> > 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) #