Re: XID wraparound and busy databases

Decibel! <decibel@decibel.org> writes:
> Aren't there potential issues with keeping the same XID if a transaction
> in the middle has modified data?

I don't see any, as long as you take a new snapshot.

> Something else to think about... any app that's doing that kind of
> transaction rate is likely going to have a large number of backends, so
> it would be even better if one XID could be shared across backends.

Not sane in the least.  What happens if two of them start to modify
data, and then one commits and one rolls back?

In any case, if we can cut the xact rate to one every few seconds per
backend, the problem goes away.

Actually ... an idea that might be worth investigating is to do
something similar to what we already did for subtransactions: don't
assign an XID at all until the transaction makes a data change.
I think that the main reason for assigning an XID earlier is just that
the ProcArray routines ignore backends that are not currently showing an
active XID when they figure global XMIN.  But a backend could probably
advertise an XMIN, indicating the age of the oldest active snapshot it's
got, without advertising an active XID.  (This could also tie into the
idea we discussed awhile back of tracking minimum XMIN better by
maintaining a central list of open snapshots within each backend.
Perhaps that should be totally decoupled from whether we are advertising
an active XID ...)
        regards, tom lane