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" pages
after checkpoint (in case a complete WAL rollforward bails out)
2. Create a consistent online backup snapshot, by first doing something like an
ordinary tar, and after that save all "physical log" pages.

Andreas