Re: Transaction Id Space, Freezing and Wraparound - Mailing list pgsql-general

Martín Fernández <fmartin91@gmail.com> writes:
> First thing that generated a lot of noise in my head was the following, if pg assigns contiguous numeric values for the txid, how does pg deal with fragmentation issues ? Then I later found that the txid space is actually circular and not linearly as I originally thought it was. This exposed me to the fact that the txid is actually exported as a 64bit value where the last 32bits are an epoch. My understanding is that the epoch is the component that allows the circularity of the data structure. I then started analyzing how pg decides if a given tuple is eligible for freezing.  I found out that pg will compare a cutoff_tx (I assume this is the last committed tx) with the xmin value of the given tuple, if xmin precedes the cutoff_tx the tuple is eligible (I’m ignoring HEAP_XMAX_IS_MULTI and HEAP_MOVED cases). Now, the xmin of a tuple is an 32 bit integer, so, how is the epoch part of an exported txid considered here ? What if we had a database really old where a txid with integer value 10 is greater than a txid of value 1000 ? 

Actually, XID epoch is an artifact that's bolted on for possible use by
replication or what have you. So far as the core database is concerned,
XIDs are 32 bits in a circular space, and the way that we deal with your
question is we don't let the case arise. Every old tuple must be marked
"frozen" before its XID gets to be 2 billion XIDs old; after that, we
don't particularly care just how old it is. The whole "wraparound"
business just exists to make sure that happens in time.

If the stored XIDs were 64 bits wide, we'd not have to bother with all
of this mess ... but adding another 64 bits to tuple headers would be
a painful space cost, not to mention the storage compatibility issues.

regards, tom lane