On Wed, May 3, 2023 at 2:59 PM Peter Geoghegan <p...@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. 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