
> > 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

Wed, 7 Mar 2001 12:58:37 +0100 
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: WAL-based allocation of XIDs is insecure
> > 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 

I believe that I explained why it's not minor issue (and never was).
Eg - PageRepaireFragmentation "compacts" page exactly like other,
overwriting, DBMSes do and partial write of modified page means
lost page content.

> > 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

What difference between consistent state as it was before checkpoint and
after that? Why should we log old page images? New (after modification) page
images are also consistent and can be used to create consistent state.

> 2. have an easy way to handle index rollforward/abort
> (might need to block some index modifications during checkpoint though)

There is no problems now. Page is either splitted (new page created/
properly initialized, right sibling updated) or not.

> 3. ease the conversion to overwrite smgr

?

> 4. ease the creation of BAR to create consistent snapshot without 
> need for log rollforward

Isn't it the same as 1. with "snapshot" == "state"?

> > 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)).

Relfilenode + TID are saved, as well as anything else that would required
to UNDO operation, in future.

> > 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 :-)
  ^^^^^^^^^^^^^^^^^^^^^
I hope so -:)

Vadim



Wed, 7 Mar 2001 04:43:41 -0800
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: WAL-based allocation of XIDs is insecure