> >> 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.
> > 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.
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-03-06 16:54:49|
|Subject: Re: How to shoot yourself in the foot: kill -9 postmaster|
|Previous:||From: Tom Lane||Date: 2001-03-06 16:17:56|
|Subject: Re: AW: AW: WAL-based allocation of XIDs is insecure |