AW: [HACKERS] beta testing version - Mailing list pgsql-general

From ZeugswetterA@Wien.Spardat.at (Zeugswetter Andreas SB)
Subject AW: [HACKERS] beta testing version
Date
Msg-id 11C1E6749A55D411A9670001FA68796336816B@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List pgsql-general
> > > 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.
> >
> > Be sure to include a CRC of each part of the block that you hope
> > to replay individually.
>
> Why should we do this? I'm not going to replay parts individually,
> I'm going to write entire pages to OS cache and than apply changes to
> them. Recovery is considered as succeeded after server is ensured
> that all applyed changes are on the disk. In the case of crash during
> recovery we'll replay entire game.

Yes, but there would need to be a way to verify the last page or record from txlog when
running on crap hardware. The point was, that crap hardware writes our 8k pages
in any order (e.g. 512 bytes from the end, then 512 bytes from front ...), and does not
even notice, that it only wrote part of one such 512 byte block when reading it back
after a crash. But, I actually doubt that this is true for all but the most crappy hardware.

Andreas


pgsql-general by date:

Previous
From: Alain Lavigne
Date:
Subject: pg_trigger
Next
From: Kevin English
Date:
Subject: cancel while waiting for a lock - how?