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
