Re: do only critical work during single-user vacuum? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: do only critical work during single-user vacuum?
Date
Msg-id CAH2-WzmKDMRH=rDGecezVBoQc9Kak5un6yy_Gu=Mn6wgfDqAaQ@mail.gmail.com
Whole thread Raw
In response to do only critical work during single-user vacuum?  (John Naylor <john.naylor@enterprisedb.com>)
List pgsql-hackers
On Mon, Jun 27, 2022 at 12:36 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> By chance, I came across this prior thread which advocated the same thing in a
> initially (rather than indirectly as in this year's thread).

Revisiting this topic reminded me that PostgreSQL 14 (the first
version that had the wraparound failsafe mechanism controlled by
vacuum_failsafe_age) has been a stable release for 9 months now. As of
today I am still not aware of even one user that ran into the failsafe
mechanism in production. It might well have happened by now, of
course, but I am not aware of any specific case. Perhaps this will
change soon enough -- maybe somebody else will read this and enlighten
me.

To me the fact that the failsafe seems to seldom kick-in in practice
suggests something about workload characteristics in general: that it
isn't all that common for users to try to get away with putting off
freezing until a table attains an age that is significantly above 1
billion XIDs.

When people talk about things like 64-bit XIDs, I tend to wonder: if 2
billion XIDs wasn't enough, why should 4 billion or 8 billion be
enough? *Maybe* the system can do better by getting even further into
debt than it can today, but you can't expect to avoid freezing
altogether (without significant work elsewhere). My general sense is
that freezing isn't a particularly good thing to try to do lazily --
even if we ignore the risk of an eventual wraparound failure.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: "Finnerty, Jim"
Date:
Subject: Re: Retrieving unused tuple attributes in ExecScan
Next
From: Jeff Davis
Date:
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access