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

[Hiroshi Inoue]

Zeugswetter Andreas SB wrote: > > > 1. A new transaction inserts a tuple. The tuple is entered into its > > heap file with the new transaction's XID, and an associated WAL log > > entry is made. Neither one of these are on disk yet --- the heap tuple > > is in a shmem disk buffer, and the WAL entry is in the shmem > > WAL buffer. > > > > 2. Now do a lot of read-only operations, in the same or another backend. > > The WAL log stays where it is, but eventually the shmem disk buffer will > > get flushed to disk so that the buffer can be re-used for some other > > disk page. > > > > 3. Assume we now crash. Now, we have a heap tuple on disk with an XID > > that does not correspond to any XID visible in the on-disk WAL log. > > > > 4. Upon restart, WAL will initialize the XID counter to the first XID > > not seen in the WAL log. Guess which one that is. > > > > 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 original page >will be > written to the log (aka physical log). Yes there must be XLogFlush() before writing buffers. BTW how do we get the next XID if WAL files are corrupted ? Regards, Hiroshi Inoue ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])