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.