Re: Transaction ID wraparound: problem and proposed solution

Tom Lane wrote:
> 
> We've expended a lot of worry and discussion in the past about what
> happens if the OID generator wraps around.  However, there is another
> 4-byte counter in the system: the transaction ID (XID) generator.
> While OID wraparound is survivable, if XIDs wrap around then we really
> do have a Ragnarok scenario.  The tuple validity checks do ordered
> comparisons on XIDs, and will consider tuples with xmin > current xact
> to be invalid.  Result: after wraparound, your whole database would
> instantly vanish from view.
> 
> The first thought that comes to mind is that XIDs should be promoted to
> eight bytes.  However there are several practical problems with this:
> * portability --- I don't believe long long int exists on all the
> platforms we support.

I suspect that gcc at least supports long long on all OS-s we support

> * performance --- except on true 64-bit platforms, widening Datum to
> eight bytes would be a system-wide performance hit, which is a tad
> unpleasant to fix a scenario that's not yet been reported from the
> field.

Complicating compares would also be a performance hit. It's hard to tell 
which one would be bigger

> * disk space --- letting pg_log grow without bound isn't a pleasant
> prospect either.

How will 2x size increase of xid cause "boundless" growth of pg_log ;)

> I believe it is possible to fix these problems without widening XID,
> by redefining XIDs in a way that allows for wraparound.  Here's my
> plan:

I'd hate to let go of any hope of restoring time travel.

I suspect that until postgres starts re-using space, time travel is in 
theory possible, provided one more file is kept with commit (wall-clock)
times of transactions or adding these times to pg_log.

BTW, is there somewhere a timetable of important changes in basic 
principles in postgres, so that I could get a CVS checkout just before 
them happening ?

I'd specially be intereted in following:

t0: system support for time-travel removed
t1: no longer a no-overwrite systems
t2: OIDs gone
t3: got rid of all OO-features ;)

----------
Hannu