AW: AW: AW: WAL-based allocation of XIDs is insecure

> >> Hmm.  Actually, what is written to the log is the *modified* page not
> >> its original contents.
> > Well, that sure is not what was discussed on the list for implementation !!
> > I thus really doubt above statement.
> 
> Read the code.

Ok, sad.

> 
> > Each page about to be modified should be written to the txlog once,
> > and only once before the first modification after each checkpoint.
> 
> Yes, there's only one page dump per page per checkpoint.  But the
> sequence is (1) make the modification in shmem buffers then (2) make
> the XLOG entry. 
> 
> I believe this is OK since the XLOG entry is flushed before any of
> the pages it affects are written out from shmem.  Since we have not
> changed the storage management policy, it's OK if heap pages contain
> changes from uncommitted transactions

Sure, but the other way would be a lot less complex.
> --- all we must avoid is
> inconsistencies (eg not all three pages of a btree split written out),
> and redo of the XLOG entry will ensure that for us.

Is it so hard to swap ? First write page to log then modify in shmem. 
Then those pages would have additional value, because
then utilities could do all sorts of things with those pages.

1. Create a consistent state of the db by only applying "physical log" pagesafter checkpoint (in case a complete WAL
rollforwardbails out)
 
2. Create a consistent online backup snapshot, by first doing something like an ordinary tar, and after that save all
"physicallog" pages.
 

Andreas