RE: beta testing version

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

Responses

Browse pgsql-hackers by date

  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