Date: Thu, 24 Jun 2021 16:06:38 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Bruce Momjian <bruce@momjian.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, eric.mutta@gmail.com,
	pgsql-docs@lists.postgresql.org
Subject: Re: 24.1.5.1. Multixacts And Wraparound
Message-ID: <202106242006.uyjdiujqk36b@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210624195329.GB16214@momjian.us>
Archived-At: 
 <https://www.postgresql.org/message-id/202106242006.uyjdiujqk36b%40alvherre.pgsql>
Precedence: bulk

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