Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing

On Sat, May 13, 2023 at 7:47 PM Greg Stark <stark@mit.edu> wrote:
> It's not like there are 2 billion XIDs in a big pool being used and
> returned and as long as you don't use too many XIDs leaving the pool
> empty you're ok. When people talk about resource exhaustion they
> imagine that they just need a faster machine or some other way of just
> putting more XIDs in the pool so they can keep using them at a faster
> rate.
>
> I really think focusing on changing one term of art for another,
> neither of which is at all meaningful without an extensive technical
> explanation helps anyone. All it does is hide all the existing
> explanations that are all over the internet from them.

Have you read the documentation in question recently? The first two
paragraphs, in particular:

https://www.postgresql.org/docs/devel/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

As I keep pointing out, we literally introduce the whole topic of
freezing/wraparound by telling users that VACUUM needs to avoid
wraparound to stop your database from becoming corrupt. Which is when
"the past becomes the future", or in simple terms data corruption
(without any qualification about single user mode being required to
corrupt the DB). Users think that that's what "wraparound" means
because we've taught them to think that. We've already been giving
users "an extensive technical explanation" for many years -- one that
happens to be both harmful and factually incorrect.

I agree that users basically don't care about unsigned vs signed vs
whatever. But there is a sense that that matters, because the docs
have made it matter. That's my starting point. That's the damage that
I'm trying to undo.

> > 1. Most cases involving xidStopLimit (or even single-user mode data
> > corruption) won't involve any kind of physical integer wraparound.
>
> Fwiw I've never actually bumped into anyone talking about integer
> overflow (which isn't usually called "wraparound" anyways). And in any
> case it's not a terrible misconception, it at least gives users a
> reasonable model for how XID space consumption works. In fact it's not
> even entirely wrong -- it's not the XID itself that's overflowing but
> the difference between the XID and the frozen XID.

Even your "not entirely wrong" version is entirely wrong. What you
describe literally cannot happen (outside of single user mode),
because xidStopLimit stops it from happening. To me your argument
seems similar to arguing that it's okay to call chemotherapy "cancer"
on the grounds that "cancer" refers to something that you really ought
to avoid in the first place in any case, which makes the whole
distinction irrelevant to non-oncologists.

That said, I concede that the term wraparound is too established to
just get rid of now. The only viable way forward now may be to
encourage users to think about it in the way that you suppose they
must already think about it. That is, to prominently point out that
"wraparound" actually refers to a protective mode of operation where
XID allocations are temporarily disallowed. And not pretty much
nothing to do with "wraparound" of the kind that the user may be
familiar with from other contexts. Including (and especially) all
earlier versions of the Postgres docs.

--
Peter Geoghegan