public inbox for [email protected]
help / color / mirror / Atom feedMinor necessary/sufficient slip-up?
3+ messages / 3 participants
[nested] [flat]
* Minor necessary/sufficient slip-up?
@ 2025-09-02 08:22 PG Doc comments form <[email protected]>
2025-09-03 07:52 ` Re: Minor necessary/sufficient slip-up? Laurenz Albe <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: PG Doc comments form @ 2025-09-02 08:22 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/routine-vacuuming.html
Description:
This is a most pedantic point, but since the postgres documentation is
incredibly accurate and well written I indulge my pedantry this one time:
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 also
sufficient. Indeed if I understand the subsequent explanation, it is
sufficient but not necessary.
Here is the full paragraph:
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 “in the future” and should not be
visible to the current transaction. But since transaction IDs have limited
size (32 bits) a cluster that runs for a long time (more than 4 billion
transactions) would suffer transaction ID wraparound: the XID counter wraps
around to zero, and all of a sudden transactions that were in the past
appear to be in the future — which means their output become invisible. In
short, catastrophic data loss. (Actually the data is still there, but that'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.
Suggested change for the last sentence:
To avoid this, it suffices to vacuum every table in every database at least
once every two billion transactions.
Bets regards,
Knut Bjarte Haus
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Minor necessary/sufficient slip-up?
2025-09-02 08:22 Minor necessary/sufficient slip-up? PG Doc comments form <[email protected]>
@ 2025-09-03 07:52 ` Laurenz Albe <[email protected]>
2025-09-03 09:58 ` Re: Minor necessary/sufficient slip-up? Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Laurenz Albe @ 2025-09-03 07:52 UTC (permalink / raw)
To: [email protected]; [email protected]
On Tue, 2025-09-02 at 08:22 +0000, PG Doc comments form wrote:
> Page: https://www.postgresql.org/docs/17/routine-vacuuming.html
>
> This is a most pedantic point, but since the postgres documentation is
> incredibly accurate and well written I indulge my pedantry this one time:
>
> 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 also
> sufficient. Indeed if I understand the subsequent explanation, it is
> sufficient but not necessary.
>
> Here is the full paragraph:
>
> 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 “in the future” and should not be
> visible to the current transaction. But since transaction IDs have limited
> size (32 bits) a cluster that runs for a long time (more than 4 billion
> transactions) would suffer transaction ID wraparound: the XID counter wraps
> around to zero, and all of a sudden transactions that were in the past
> appear to be in the future — which means their output become invisible. In
> short, catastrophic data loss. (Actually the data is still there, but that'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.
>
> Suggested change for the last sentence:
> To avoid this, it suffices to vacuum every table in every database at least
> once every two billion transactions.
I don't think that that would be an improvement. Yes, it is sufficient, but
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Minor necessary/sufficient slip-up?
2025-09-02 08:22 Minor necessary/sufficient slip-up? PG Doc comments form <[email protected]>
2025-09-03 07:52 ` Re: Minor necessary/sufficient slip-up? Laurenz Albe <[email protected]>
@ 2025-09-03 09:58 ` Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Peter Eisentraut @ 2025-09-03 09:58 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; [email protected]; [email protected]
On 03.09.25 09:52, Laurenz Albe wrote:
> On Tue, 2025-09-02 at 08:22 +0000, PG Doc comments form wrote:
>> Page: https://www.postgresql.org/docs/17/routine-vacuuming.html
>>
>> This is a most pedantic point, but since the postgres documentation is
>> incredibly accurate and well written I indulge my pedantry this one time:
>>
>> 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 also
>> sufficient. Indeed if I understand the subsequent explanation, it is
>> sufficient but not necessary.
>>
>> Here is the full paragraph:
>>
>> 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 “in the future” and should not be
>> visible to the current transaction. But since transaction IDs have limited
>> size (32 bits) a cluster that runs for a long time (more than 4 billion
>> transactions) would suffer transaction ID wraparound: the XID counter wraps
>> around to zero, and all of a sudden transactions that were in the past
>> appear to be in the future — which means their output become invisible. In
>> short, catastrophic data loss. (Actually the data is still there, but that'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.
>>
>> Suggested change for the last sentence:
>> To avoid this, it suffices to vacuum every table in every database at least
>> once every two billion transactions.
>
> I don't think that that would be an improvement. Yes, it is sufficient, but
> 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?
I think this introductory sentence establishes the necessity only. The
rest of the section and chapter establishes the sufficiency.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-09-03 09:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-09-02 08:22 Minor necessary/sufficient slip-up? PG Doc comments form <[email protected]>
2025-09-03 07:52 ` Laurenz Albe <[email protected]>
2025-09-03 09:58 ` Peter Eisentraut <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox