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

Re: WAL-based allocation of XIDs is insecure

From: Ian Lance Taylor <ian(at)airs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WAL-based allocation of XIDs is insecure
Date: 2001-03-05 19:35:56
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> After thinking about this for a little, it seems to me that XID
> assignment should be handled more like OID assignment: rather than
> handing out XIDs one-at-a-time, varsup.c should allocate them in blocks,
> and should write an XLOG record to reflect the allocation of each block
> of XIDs.  Furthermore, the above example demonstrates that *we must
> flush that XLOG entry to disk* before we can start to actually hand out
> the XIDs.  This ensures that the next system cycle won't re-use any XIDs
> that may have been in use at the time of a crash.

I think your example demonstrates something slightly different.  I
think it demonstrates that Postgres must flush the XLOG entry to disk
before it flushes any buffer to disk which uses an XID which was just

For each buffer, heap_update could record the last XID stored into
that buffer.  When a buffer is forced out to disk, Postgres could make
sure that the XLOG entry which uses the XID is previously forced out
to disk.

A simpler and less accurate approach: when any dirty buffer is forced
to disk in order to allocate a buffer, make sure that any XLOG entry
which allocates new XIDs is flushed to disk first.

I don't know if these are better.  I raise them because you are
suggesting putting an occasional fsync at transaction start to avoid
an unlikely scenario.  A bit of bookkeeping can be used instead to
notice the unlikely scenario when it occurs.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-05 19:43:20
Subject: Re: How to handle waitingForLock in LockWaitCancel()
Previous:From: Tom LaneDate: 2001-03-05 19:00:59
Subject: Re: Uh, this is *not* a 64-bit CRC ...

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