From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <jwieck(at)debis(dot)com> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, dhogaza(at)pacifier(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Priorities for 6.6 |
Date: | 1999-06-07 01:24:02 |
Message-ID: | 199906070124.VAA18065@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-06-07 01:33:21 | Re: [HACKERS] Open 6.5 items |
Previous Message | Bruce Momjian | 1999-06-07 01:16:45 | Re: [HACKERS] Priorities for 6.6 |