> > In short I do not think that the current implementation of
> > "physical log" does what it was intended to do :-(
>
> Hm, wasn't it handling non-atomic disk writes, Andreas?
Yes, but for me, that was only one (for me rather minor) issue.
I still think that the layout of PostgreSQL pages was designed to
reduce the risc of a (heap) page beeing inconsistent because it is
only partly written to an acceptable minimum. If your hw and os can
guarantee that it does not overwrite one [OS] block with data that was
not supplied (== junk data), the risc is zero.
> And for what else "physical log" could be used?
1. create a consistent state if rollforward bails out for some reason
but log is still readable
2. have an easy way to handle index rollforward/abort
(might need to block some index modifications during checkpoint though)
3. ease the conversion to overwrite smgr
4. ease the creation of BAR to create consistent snapshot without
need for log rollforward
> Now, why should we log page as it was *before* modification?
> We would log modification anyway (yet another log record!) and
Oh, so currently you only do eighter ? I would at least add the
info which slot was inserted/modified (maybe that is already there (XID)).
> would apply it to page, so result would be the same as now when
> we log page after modification - consistent *modifyed* page.
Maybe I am too focused on the implementation of one particular db,
that I am not able to see this without prejudice, and all is well as is :-)
Andreas
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
