Re: Transaction ID wraparound: problem and proposed solution

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction ID wraparound: problem and proposed solution
Date: 2000-11-05 14:00:31
Message-ID: 3A0567FF.37876138@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2000-11-05 14:15:33 Re: Summary: what to do about INET/CIDR
Previous Message Hannu Krosing 2000-11-05 13:48:13 Re: Transaction ID wraparound: problem and proposed solution