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