Exercise 1: How Postgres Implements MVCC via xmin/xmax, and Why This Creates Dead Tuples — Possible Solution
====================================================================

HOW POSTGRES PHYSICALLY IMPLEMENTS MVCC
------------------------------
Per this chapter, "every Postgres row (tuple) carries hidden system
columns xmin and xmax — xmin records the transaction ID that created
this row version, xmax records the transaction ID that deleted or
superseded it." Every row physically stored on disk carries these two
hidden markers recording which transaction created it and, if
applicable, which transaction superseded it. Per the chapter, "an
UPDATE in Postgres never modifies a row in place — it creates an
entirely new tuple with a new xmin, and sets xmax on the old tuple to
mark it superseded."

Concretely: when a row is updated, Postgres doesn't change the
existing bytes on disk to reflect the new values. It writes a
brand-new tuple elsewhere, with its own new xmin set to the current
transaction's ID, containing the updated values. It then goes back
and sets xmax on the ORIGINAL tuple to that same transaction ID,
marking that original version as "superseded as of this transaction"
— but the original tuple's own bytes are left physically in place,
unchanged, at least for now.

WHY THIS CREATES DEAD TUPLES AS A DIRECT, STRUCTURAL CONSEQUENCE
------------------------------
Per this chapter, "that old version isn't removed immediately; it
becomes a dead tuple," and later: "this is the direct, structural
consequence of Postgres's own 'new tuple per update' strategy: every
UPDATE and DELETE leaves behind dead tuples — no longer visible to
any current or future transaction, but still physically occupying
disk space until cleaned up."

The mechanism ITSELF is what creates the dead tuple — it's not an
occasional side effect or a bug, it's the unavoidable, direct result
of choosing to never modify a row in place. Since the old tuple's
bytes are never overwritten by the UPDATE itself (only marked via
xmax), that space remains physically occupied on disk, containing
data no longer relevant to any future query, until something else
(VACUUM) comes along specifically to reclaim it. Every single UPDATE
or DELETE, by definition, leaves exactly this kind of leftover behind.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the xmin/xmax mechanism concretely, step by step through
what happens during an UPDATE, and explicitly connects that mechanism
to WHY dead tuples are an inevitable, structural byproduct rather than
an occasional or avoidable side effect.