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