Message-ID: <676bd6741c0ea1195b8d65231edb96eeee5f9cc7.camel@cybertec.at>
Subject: Re: Minor necessary/sufficient slip-up?
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: knut.b.haus@gmail.com, pgsql-docs@lists.postgresql.org
Date: Wed, 03 Sep 2025 09:52:56 +0200
In-Reply-To: <175680133226.771.1421809976333381466@wrigleys.postgresql.org>
References: <175680133226.771.1421809976333381466@wrigleys.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/676bd6741c0ea1195b8d65231edb96eeee5f9cc7.camel%40cybertec.at>
Precedence: bulk

On Tue, 2025-09-02 at 08:22 +0000, PG Doc comments form wrote:
> Page: https://www.postgresql.org/docs/17/routine-vacuuming.html
>=20
> This is a most pedantic point, but since the postgres documentation is
> incredibly accurate and well written I indulge my pedantry this one time:
>=20
> Regarding the last sentence of the first paragraph of 24.1.5: I sure hope
> vacuuming every table in every database at least once every two billion
> transactions is not only necessary to avoid catastrophic data loss, but a=
lso
> sufficient. Indeed if I understand the subsequent explanation, it is
> sufficient but not necessary.
>=20
> Here is the full paragraph:
>=20
> 24.1.5. Preventing Transaction ID Wraparound Failures
> PostgreSQL's MVCC transaction semantics depend on being able to compare
> transaction ID (XID) numbers: a row version with an insertion XID greater
> than the current transaction's XID is =E2=80=9Cin the future=E2=80=9D and=
 should not be
> visible to the current transaction. But since transaction IDs have limite=
d
> size (32 bits) a cluster that runs for a long time (more than 4 billion
> transactions) would suffer transaction ID wraparound: the XID counter wra=
ps
> around to zero, and all of a sudden transactions that were in the past
> appear to be in the future =E2=80=94 which means their output become invi=
sible. In
> short, catastrophic data loss. (Actually the data is still there, but tha=
t's
> cold comfort if you cannot get at it.) To avoid this, it is necessary to
> vacuum every table in every database at least once every two billion
> transactions.
>=20
> Suggested change for the last sentence:
> To avoid this, it suffices to vacuum every table in every database at lea=
st
> once every two billion transactions.

I don't think that that would be an improvement.  Yes, it is sufficient, bu=
t
it is also necessary.  And the "necessary" part is the more important one.
As reader, I would implicitly assume that VACUUM is sufficient, otherwise
the nice writers of the documentation would surely have told me what else I
have to do to avoid that scary eventuality.

I'd be OK with writing "necessary and sufficient".  Or is that too much
legalese?

Yours,
Laurenz Albe