<para>

Another identifier type used by the system is <type>xid</>, or transaction

(abbreviated <abbrev>xact</>) identifier. This is the data type of the system columns

<structfield>xmin</> and <structfield>xmax</>. Transaction identifiers are 32-bit quantities.

<structfield>xmin</> and <structfield>xmax</>.

In <productname>&productname;</productname>, transaction IDs

are implemented as 64-bit counters to prevent transaction ID wraparound.

For details, see <xref linkend="vacuum-for-wraparound">.

</para>

<para>

A third identifier type used by the system is <type>cid</>, or

command identifier. This is the data type of the system columns

<structfield>cmin</> and <structfield>cmax</>. Command identifiers arealso32-bit quantities.

<structfield>cmin</> and <structfield>cmax</>. Command identifiers are 32-bit quantities.

</para>

<para>

</para>

<para>

Transaction identifiers are also 32-bit quantities. In a

long-lived database it is possible for transaction IDs to wrap

around. This is not a fatal problem given appropriate maintenance

procedures; see <xref linkend="maintenance"> for details. It is

unwise, however, to depend on the uniqueness of transaction IDs

over the long term (more than one billion transactions).

In <productname>&productname;</productname>, transaction IDs

are implemented as 64-bit counters to prevent transaction ID wraparound.

For details, see <xref linkend="vacuum-for-wraparound">.

</para>

<para>

Command identifiers arealso32-bit quantities. This creates a hard limit

Command identifiers are 32-bit quantities. This creates a hard limit

of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands

within a single transaction. In practice this limit is not a

problem &mdash; note that the limit is on the number of

</table>

<para>

The internal transaction ID type (<type>xid</>) is 32 bits wide and

wraps around every 4 billion transactions. However, these functions

In <productname>&productname;</productname>, transaction IDs

are implemented as 64-bit counters to prevent transaction ID wraparound.

The following functions

export a 64-bit format that is extended with an <quote>epoch</> counter

so it will not wrap around during the life of an installation.

The data type used by these functions, <type>txid_snapshot</type>,

<productname>Postgres Pro Enterprise 9.6</productname> introduced

64-bit transaction IDs, which are not subject to wraparound and

do not need modulo-2<superscript>32</> arithmetic to be compared.

Each tuple headercontain two XIDs, so extending them would lead to

Each tuple headercontains two XIDs, so extending them would lead to

high overhead. For that reason on-page XIDs are still 32-bit, but

each page's header contains an offset, called <firstterm>epoch</>,

to which they are added before comparing with each other.