Re: AW: WAL-based allocation of XIDs is insecure

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