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

Tue, 6 Mar 2001 17:38:50 +0100 
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: AW: AW: WAL-based allocation of XIDs is insecure 
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> 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.

After thinking about this a little, I believe I see why Vadim did it
the way he did.  Suppose we tried to make the code sequence be

	obtain write lock on buffer;
	XLogOriginalPage(buffer);   // copy page to xlog if first since ckpt
	modify buffer;
	XLogInsert(xlog entry for modification);
	mark buffer dirty and release write lock;

so that the saving of the original page is a separate xlog entry from
the modification data.  Looks easy, and it'd sure simplify XLogInsert
a lot.  The only problem is it's wrong.  What if a checkpoint occurs
between the two XLOG records?

The decision whether to log the whole buffer has to be atomic with the
actual entry of the xlog record.  Unless we want to hold the xlog insert
lock for the entire time that we're (eg) splitting a btree page, that
means we log the buffer after the modification work is done, not before.

			regards, tom lane

Tue, 06 Mar 2001 11:58:12 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: AW: AW: WAL-based allocation of XIDs is insecure 
I wrote:
> The decision whether to log the whole buffer has to be atomic with the
> actual entry of the xlog record.  Unless we want to hold the xlog insert
> lock for the entire time that we're (eg) splitting a btree page, that
> means we log the buffer after the modification work is done, not before.

On third thought --- we could still log the original page contents and
the modification log record atomically, if what were logged in the xlog
record were (essentially) the parameters to the operation being logged,
not its results.  That is, make the log entry before you start doing the
mod work, not after.  This might also simplify redo, since redo would be
no different from the normal case.  I'm not sure why Vadim didn't choose
to do it that way; maybe there's some other fine point I'm missing.

In any case, it'd be a big code change and not something I'd want to
undertake at this point in the release cycle ... maybe we can revisit
this issue for 7.2.

			regards, tom lane

Tue, 06 Mar 2001 12:31:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: AW: AW: WAL-based allocation of XIDs is insecure 