On Wed, Nov 5, 2025 at 6:43 AM Naga Appani <[email protected]> wrote: > > Understanding > ============ > Based on reading the relevant parts of multixact.c and observing the runtime > behavior, both approaches seem to run into limitations when trying to derive a > “remaining members” value outside the backend. I may be missing details, but > the > behavior I observed suggests that a reliable computation might require > duplicating > several internal mechanisms, including: > - wrap-aware offset comparison > - SLRU page and segment alignment rules > - SetOffsetVacuumLimit’s segment recalculation > > Without accounting for those, the derived numbers behaved inconsistently > across > tests, sometimes staying at 0 until a large jump, and in other cases > increasing > between exhaustion cycles. This seems broadly consistent with your concern > that > simple arithmetic on these counters does not match how the backend determines > wraparound risk. > > To be clear, this interpretation is based only on what I could infer from the > code and testing, and I may not be capturing the entire picture. But from > what I > observed, a user-visible “remaining members” metric does not seem > straightforward > without exposing or replicating backend logic.
Right now MultiXactOffsetWouldWrap() assesses if the given distance is higher than the permitted distance between start and boundary. I think we could instead change it to report the permitted distance based on start and boundary; use it to report remaining space (after multiplying it with bytes per member) and also use it to assess whether the required distance is within that boundary or whether we need a warning. But ... On Sat, Oct 18, 2025 at 4:48 PM Tomas Vondra <[email protected]> wrote: > > Thanks for working on this. I'm wondering if this is expected / could > help with monitoring for "space exhaustion" issues, which we currently > can't do easily, as it's not exposed anywhere. > > This is in multixact.c at line ~1177, where we do this: > > if (MultiXactState->oldestOffsetKnown && > MultiXactOffsetWouldWrap(MultiXactState->offsetStopLimit, > nextOffset, nmembers)) > { > ereport(ERROR, ... > } > > But I'm not sure the current patch exposes enough information to > calculate how much space remains - calculating that we requires > offsetStopLimit and nextOffset. The function exposes the number of existing members and the amount of space they consume (members_size). The documentation mentions space related thresholds 10GB and 20GB. Isn't comparing members_size to these thresholds enough to take appropriate action? If so, we could report the difference between these respective thresholds and members_size as a metric of space remaining before a given threshold is triggered. -- Best Wishes, Ashutosh Bapat
