Skip site navigation (1) Skip section navigation (2)

AW: WAL-based allocation of XIDs is insecure

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: WAL-based allocation of XIDs is insecure
Date: 2001-03-06 08:25:08
Message-ID: 11C1E6749A55D411A9670001FA687963368223@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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

Responses

pgsql-hackers by date

Next:From: Peter T MountDate: 2001-03-06 09:39:09
Subject: RE: CORBA and PG
Previous:From: Alfred PerlsteinDate: 2001-03-06 05:43:13
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group