Re: What is "wraparound failure", really? - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: What is "wraparound failure", really? |
Date | |
Msg-id | 59a2f44e-8473-215d-bf6a-6c85884dea34@dunslane.net Whole thread Raw |
In response to | Re: What is "wraparound failure", really? (Peter Geoghegan <pg@bowt.ie>) |
Responses |
Re: What is "wraparound failure", really?
Re: What is "wraparound failure", really? |
List | pgsql-hackers |
On 6/28/21 2:39 AM, Peter Geoghegan wrote: > On Sun, Jun 27, 2021 at 4:23 PM Andrew Dunstan <andrew@dunslane.net> wrote: > >> 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. > Sure, I'm not suggesting the docs can't have some improvement. This is one of those things that in my experience most people don't get. Indeed, I didn't really get it either until I had to explain it with some clarity to a very confused customer. And I find it's best explained by showing what bad results are being avoided by it. Freezing is one of those almost useless things you just have to do. It doesn't help that it's tangled up with VACUUM, so when you explain that it's not about reclaiming dead space heads start to explode. But if you're really worried about people setting autovacuum_freeze_max_age too high, then maybe we should be talking about capping it at a lower level rather than adjusting the docs that most users don't read. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql-hackers by date: