From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Don Baccus'" <dhogaza(at)pacifier(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: beta testing version |
Date: | 2000-12-05 18:43:03 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D31C8@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> As far as I know (and have tested in excess) Informix IDS
> does survive any power loss without leaving the db in a
> corrupted state. The basic technology is, that it only relys
> on writes to one "file" (raw device in that case), the txlog,
> which is directly written. All writes to the txlog are basically
> appends to that log. Meaning that all writes are sync writes to
> the currently active (== last) page. All other IO is not a problem,
> because a backup image "physical log" is kept for each page
> that needs to be written. During fast recovery the content of the
> physical log is restored to the originating pages (thus all pendig
> IO is undone) before rollforward is started.
Sounds great! We can follow this way: when first after last checkpoint
update to a page being logged, XLOG code can log not AM specific update
record but entire page (creating backup "physical log"). During after
crash recovery such pages will be redone first, ensuring page consistency
for further redo ops. This means bigger log, of course.
Initdb will not be required for these code changes, so it can be
implemented in any 7.1.X, X >=1.
Thanks, Andreas!
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2000-12-05 18:49:01 | RE: Wrong FOR UPDATE lock type |
Previous Message | Ross J. Reedstrom | 2000-12-05 17:39:13 | Re: beta testing version |