Re: Transaction Id Space, Freezing and Wraparound

From: Martín Fernández <fmartin91(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Transaction Id Space, Freezing and Wraparound
Date: 2018-11-20 21:27:44
Message-ID: 5bf4794bab1e814ed9000009@polymail.io
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Martín

On Tue, Nov 20th, 2018 at 6:0 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>
>
>
> =?UTF-8?q?Mart=C3=ADn_Fern=C3=A1ndez?= < fmartin91(at)gmail(dot)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
>
>
>
>

Tom,

Thanks for the insight!!

I got confused with the comment under "Transaction IDs and Snapshots"( https://www.postgresql.org/docs/current/functions-info.html ) "The internal transaction ID type (xid) is 32 bits wide and wraps around every 4 billion transactions. However, these functions export a 64-bit format that is extended with an "epoch" counter so it will not wrap around during the life of an installation. "

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Wyatt Alt 2018-11-21 02:36:23 Re: replication lag despite corrective config
Previous Message Tom Lane 2018-11-20 21:00:17 Re: Transaction Id Space, Freezing and Wraparound