> 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(xl
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 be
> >> 5. We will now run a new transaction with the same XID that was in use
> >> before the crash. If that transaction commits, then we have a tuple on
> >> disk that will be considered valid --- and should not be.
>
> > I do not think this is true. Before any modification to a page the
> > ori
Zeugswetter Andreas SB <[EMAIL PROTECTED]> 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
> >> 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 shou
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Hmm. Actually, what is written to the log is the *modified* page not
>> its original contents.
> 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 befo
> > > 5. We will now run a new transaction with the same XID that was in use
> > > before the crash. If that transaction commits, then we have a tuple on
> > > disk that will be considered valid --- and should not be.
> >
> > I do not think this is true. Before any modification to a page the ori
