On Tue, Nov 29, 2022 at 5:50 PM Bruce Momjian <bruce@momjian.us> wrote:
> doc: add transaction processing chapter with internals info
This patch added something about 32-bit transaction IDs:
+ <para>
+ The internal transaction ID type <type>xid</type> is 32 bits wide
+ and <link linkend="vacuum-for-wraparound">wraps around</link> every
+ 4 billion transactions. A 32-bit epoch is incremented during each
+ wraparound. There is also a 64-bit type <type>xid8</type> which
+ includes this epoch and therefore does not wrap around during the
+ life of an installation; it can be converted to xid by casting.
+ The functions in <xref linkend="functions-pg-snapshot"/>
+ return <type>xid8</type> values. Xids are used as the
+ basis for <productname>PostgreSQL</productname>'s <link
+ linkend="mvcc">MVCC</link> concurrency mechanism and streaming
+ replication.
+ </para>
(I noticed this during unrelated work on the VACUUM documentation,
with a focus on freezing.)
I think that it's quite reasonable to point out that there are
"truncated" 32-bit and 64-bit forms of XIDs, since advanced users are
likely to encounter both forms. However, I wonder why you're linking
to "vacuum-for-wraparound" here. What's it adding?
While it is of course true that freezing (and autovacuums to prevent
wraparound) are not *completely* unrelated, they're still very far
removed from what this is talking about. I think that it's just
confusing to connect the two issues.
The condition that is sometimes called "wraparound failure"
(internally referred to as the xidStopLimit mechanism) triggers when
the oldest relfrozenxid is a little over 2 billion XIDs old -- not 4
billion XIDs old. My concern is that the reader will conflate
wraparound of integers (a property of how unsigned 32-bit integers
work that can affect any individual integer) with something much more
specific to Postgres (confusion about whether some XID is in the past
or in the future, which is a problem that used to occur that affected
the system's ability to keep track of the logical state of the
database as a whole).
You're talking about how a 32-bit XID and a 32-bit epoch map directly
to a 64-bit transaction ID -- which does make sense. But why do you
need to talk about something that VACUUM does that is (in part) needed
to avoid storing an epoch inside every tuple header? The on-disk XIDs
in tuple headers *don't* ever wraparound -- they get frozen (or maybe
in extreme cases they prevent new XIDs from being allocated and
creating confusion about the past and the future).
--
Peter Geoghegan