Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing - Mailing list pgsql-hackers

From samay sharma
Subject Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing
Date
Msg-id CAJxrbywiYncHsvwo90wMJeuqKL9UVUmpNZ0kSZYz1fs8LxXcMA@mail.gmail.com
Whole thread Raw
In response to Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing
Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing
List pgsql-hackers
Hi,

On Wed, May 3, 2023 at 3:48 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Wed, May 3, 2023 at 2:59 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Coming up with a new user-facing name for xidStopLimit is already on
> my TODO list (it's surprisingly hard). I have used that name so far
> because it unambiguously refers to the exact thing that I want to talk
> about when discussing the worst case. Other than that, it's a terrible
> name.

What about "XID allocation overload"? The implication that I'm going
for here is that the system was misconfigured, or there was otherwise
some kind of imbalance between XID supply and demand. It also seems to
convey the true gravity of the situation -- it's *bad*, to be sure,
but in many environments it's a survivable condition.

My concern with the term "overload" is similar to what you expressed below. It indicates that the situation is due to extra load on the system (or due to too many XIDs being allocated) and people might assume that the situation will resolve itself if the load were to be reduced / removed. However, it's due to that along with some misconfiguration or some other thing holding back the "removable cutoff".

What do you think about the term "Exhaustion"? Maybe something like "XID allocation exhaustion" or "Exhaustion of allocatable XIDs"? The term indicates that we are running out of XIDs to allocate without necessarily pointing towards a reason.

Regards,
Samay
 

One possible downside of this name is that it could suggest that all
that needs to happen is for autovacuum to catch up on vacuuming. In
reality the user *will* probably have to do more than just wait before
the system's ability to allocate new XIDs returns, because (in all
likelihood) autovacuum just won't be able to catch up unless and until
the user (say) drops a replication slot. Even still, the name seems to
work; it describes the conceptual model of the system accurately. Even
before the user drops the replication slot, autovacuum will at least
*try* to get the system back to being able to allocate new XIDs once
more.

--
Peter Geoghegan

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A bug with ExecCheckPermissions
Next
From: Andrew Dunstan
Date:
Subject: Re: ssl tests aren't concurrency safe due to get_free_port()