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
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 |