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
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 |