From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Subject: | Re: What is "wraparound failure", really? |
Date: | 2021-06-28 12:51:50 |
Message-ID: | 59a2f44e-8473-215d-bf6a-6c85884dea34@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/28/21 2:39 AM, Peter Geoghegan wrote:
> On Sun, Jun 27, 2021 at 4:23 PM Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-06-28 12:52:16 | Re: pgindent run |
Previous Message | Andrew Dunstan | 2021-06-28 12:29:10 | pgindent run |