Re: 24.1.5.1. Multixacts And Wraparound

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, eric(dot)mutta(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: 24.1.5.1. Multixacts And Wraparound
Date: 2021-06-24 20:06:38
Message-ID: 202106242006.uyjdiujqk36b@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On 2021-Jun-24, Bruce Momjian wrote:

> + As a safety device, an aggressive vacuum scan will
> + occur for any table whose multixact-age (see <xref
> + linkend="vacuum-for-multixact-wraparound"/>) is greater than <xref
> + linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the
> + storage occupied by multixacts exceeds 2GB, aggressive vacuum scans
> + will occur more often for all tables, starting with those that have
> + the oldest multixact-age. Both of these kinds of aggressive scans
> + will occur even if autovacuum is nominally disabled.

This looks good, thanks.

I think "the space occupied by multixacts" is a bit ambiguous -- it is
talking about pg_multixact/members only, but you could interpret that it
talks about both that and pg_multixact/offsets. I'm not sure we need to
be 100% precise about that, so perhaps what you have is sufficient. But
if we do want to be precise, then maybe " ... if the storage occupied by
multixact members (<literal>pg_multixact/members/</literal>) exceeds ..."
covers it.

(At least, that's how I remember this. I don't think things have
changed much since 53bb309d2d5a ...)

--
Álvaro Herrera Valdivia, Chile

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Eisentraut 2021-06-25 06:17:10 Re: change float4 to floating point about type of autovacuum_vacuum_insert_scale_factor
Previous Message Bruce Momjian 2021-06-24 19:53:29 Re: 24.1.5.1. Multixacts And Wraparound