AW: WAL-based allocation of XIDs is insecure

> 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).
On startup rollforward this original page, that does not contain the inserted
tuple with the stale XID is rewritten over the modified page.

Andreas

PS: I thus object to your proposed XID allocation change