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-WzkEmTO6P99toM43xRR=HZhA2CV6moqsRPZUeq9SVd0Xmg@mail.gmail.com
Whole thread Raw
In response to Re: do only critical work during single-user vacuum?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sun, Feb 20, 2022 at 2:15 PM Andres Freund <andres@anarazel.de> wrote:
> We could e.g. add an error if FreezeMultiXactId() needs to create a new
> multixact for a far-in-the-past xid. That's not great, of course, but if we
> include the precise cause (pid of backend / prepared xact name / slot name /
> ...) necessitating creating a new multi, it'd still be a significant
> improvement over the status quo.

There are databases that have large tables (that grow and grow), and
also have tables that need to allocate many MultiXacts (or lots of
member space, at least). I strongly suspect that these are seldom the
same table, though.

The current inability of the system to recognize this difference seems
like it might be a real problem. Why should big tables that contain no
actual MultiXactIds at all (and never contained even one) get early
anti-wraparound VACUUMs, specifically focussed on averting MultiXact
wraparound? I'm hoping that the patch that adds smarter tracking of
final relfrozenxid/relminmxid values during VACUUM makes this less of
a problem automatically.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: do only critical work during single-user vacuum?
Next
From: Tom Lane
Date:
Subject: Re: Fix overflow in DecodeInterval