Re: What is "wraparound failure", really?

On Sun, Jun 27, 2021 at 4:23 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> AIUI, actual wraparound (i.e. an xid crossing the event horizon so it
> appears to be in the future) is no longer possible. But it once was a
> very real danger. Maybe the docs haven't quite caught up.

This was added a few years after freezing was first invented, which
was arguably the last time that the design fundamentally changed. I
think we all agree that it's fundamentally not okay to give wrong
answers to queries -- it doesn't even need to be stated in the docs
IMV. So why does this section of the docs spend so much time talking
about something that fundamentally cannot happen? Why not have it
focus on the bad outcome that there is a real risk of instead? Namely
the risk of the system refusing to allow new XIDs (as a means of
avoiding the wrong answers when all else fails).

It's hard to talk about the new failsafe in this section of the docs
now, since it's unclear whether it exists to advise the user on ways
of avoiding the "can't allocate XIDs" failure mode. It could be
interpreted that way, or it could just be explaining and/or justifying
the existence of the failure mode. That seems like a real problem.

> In practical terms, there is an awful lot of head room between the
> default for autovacuum_freeze_max_age and any danger of major
> anti-wraparound measures. Say you increase it to 1bn from the default
> 200m. That still leaves you ~1bn transactions of headroom.

I agree that in practice that's often fine. But my point is that there
is another very good reason to not increase autovacuum_freeze_max_age,
contrary to what the docs say (actually there is a far better reason
than truncating clog). Namely, increasing it will generally increase
the risk of VACUUM not finishing in time. If that happens the user
gets the "can't allocate XIDs" failure mode (which is what I have
called wraparound failure up until now), which is one of the worst
things that can happen. This makes the inability to truncate clog look
like a totally trivial issue in comparison.

Reasonable people can disagree about when and how increasing
autovacuum_freeze_max_age becomes truly reckless. However, I don't
think that anybody would be willing to argue that setting it to the
maximum of 2 billion could ever make sense in production, to go with
the obvious extreme case. The benefits that you get from such a high
setting over and above what you get with a moderately high setting
(perhaps 1 - 1.5 billion) are really quite small, while the risk
shoots up fast past a certain point.

Regardless of what the nuances of increasing autovacuum_freeze_max_age
are, stating that the sole disadvantage is that you cannot truncate
clog and other SLRUs is clearly wrong.

--
Peter Geoghegan