AW: AW: AW: AW: [HACKERS] WAL-based allocation of XIDs is insecure

2001-03-06 Thread Zeugswetter Andreas SB
> 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

Re: AW: AW: AW: [HACKERS] WAL-based allocation of XIDs is insecure

2001-03-06 Thread Tom Lane
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

Re: AW: AW: AW: [HACKERS] WAL-based allocation of XIDs is insecure

2001-03-06 Thread Tom Lane
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

AW: AW: AW: [HACKERS] WAL-based allocation of XIDs is insecure

2001-03-06 Thread Zeugswetter Andreas SB
> >> 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