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

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

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: WAL-based allocation of XIDs is insecure
Date: 2001-03-06 10:21:26
Message-ID: 3AA4BA26.EC3ECBB4@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Vince VielhaberDate: 2001-03-06 11:11:46
Subject: Banner links not working (fwd)
Previous:From: Peter T MountDate: 2001-03-06 09:39:09
Subject: RE: CORBA and PG

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