From: | samay sharma <smilingsamay(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing |
Date: | 2023-05-04 22:18:33 |
Message-ID: | CAJxrbywiYncHsvwo90wMJeuqKL9UVUmpNZ0kSZYz1fs8LxXcMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Wed, May 3, 2023 at 3:48 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Wed, May 3, 2023 at 2:59 PM Peter Geoghegan <pg(at)bowt(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-05-04 22:33:47 | Re: ssl tests aren't concurrency safe due to get_free_port() |
Previous Message | Tom Lane | 2023-05-04 22:11:49 | Re: A bug with ExecCheckPermissions |