database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-21 15:54:08 +03:00
Code

Doc: correct aggressive vacuum threshold for multixact members storage

Browse Source 
The threshold is two billion members, which was interpreted as 2GB
in the documentation. Fix to reflect that each member takes up five
bytes, which translates to about 10GB. This is not exact, because of
page boundaries. While at it, mention the maximum size 20GB.

This has been wrong since commit c552e171d16e, so backpatch to
version 14.

Author: Alex Friedman <alexf01@gmail.com>
Reviewed-by: Sami Imseih <samimseih@gmail.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Discussion: https://postgr.es/m/CACbFw60UOk6fCC02KsyT3OfU9Dnuq5roYxdw2aFisiN_p1L0bg@mail.gmail.com
Backpatch-through: 14
This commit is contained in:
John Naylor 2025-03-07 10:22:56 +07:00
parent 9094eb25b7
commit 5c8dcf9483
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/sgml/maintenance.sgml
View File

@ -793,10 +793,11 @@ HINT: Execute a database-wide VACUUM in that database.
As a safety device, an aggressive vacuum scan will
occur for any table whose multixact-age is greater than <xref
linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the
storage occupied by multixacts members exceeds 2GB, aggressive vacuum
storage occupied by multixacts members exceeds about 10GB, 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.
scans will occur even if autovacuum is nominally disabled. The members storage
area can grow up to about 20GB before reaching wraparound.
</para>
<para>