From 6533c459706ab74b2206bb085ef1c9b800a8e656 Mon Sep 17 00:00:00 2001 From: PegoraroF10 Date: Thu, 30 Jul 2026 11:31:06 -0300 Subject: [PATCH] =?UTF-8?q?=E2=80=8BSome=20sentences=20in=20the=20document?= =?UTF-8?q?ation=20have=20become=20strange=20or=20incomplete=20since=20REP?= =?UTF-8?q?ACK=20command=20was=20added.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/src/sgml/ddl.sgml | 3 ++- doc/src/sgml/maintenance.sgml | 16 ++++++++++------ doc/src/sgml/monitoring.sgml | 4 ++-- doc/src/sgml/mvcc.sgml | 10 ++++++---- 4 files changed, 20 insertions(+), 13 deletions(-) diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 5e8c270ab3a..cace493f495 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1568,7 +1568,8 @@ CREATE TABLE circles ( although the ctid can be used to locate the row version very quickly, a row's ctid will change if it is - updated or moved by VACUUM FULL. Therefore + updated or moved by REPACK, + CLUSTER or VACUUM FULL. Therefore ctid should not be used as a row identifier. A primary key should be used to identify logical rows. diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 0eec6e2e888..c2d7d5ef4e8 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -171,7 +171,8 @@ future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be - easily obtained. In contrast, VACUUM FULL actively compacts + easily obtained. In contrast, REPACK, + CLUSTER or VACUUM FULL actively compacts tables by writing a complete new version of the table file with no dead space. This minimizes the size of the table, but can take a long time. It also requires extra disk space for the new copy of the table, until @@ -186,11 +187,13 @@ is not to keep tables at their minimum size, but to maintain steady-state usage of disk space: each table occupies space equivalent to its minimum size plus however much space gets used up between vacuum runs. - Although VACUUM FULL can be used to shrink a table back + Although REPACK, CLUSTER or + VACUUM FULL can be used to shrink a table back to its minimum size and return the disk space to the operating system, there is not much point in this if the table will just grow again in the future. Thus, moderately-frequent standard VACUUM runs are a - better approach than infrequent VACUUM FULL runs for + better approach than infrequent REPACK, + CLUSTER or VACUUM FULL runs for maintaining heavily-updated tables. @@ -199,7 +202,8 @@ doing all the work at night when load is low. The difficulty with doing vacuuming according to a fixed schedule is that if a table has an unexpected spike in update activity, it may - get bloated to the point that VACUUM FULL is really necessary + get bloated to the point that REPACK, + CLUSTER or VACUUM FULL is really necessary to reclaim space. Using the autovacuum daemon alleviates this problem, since the daemon schedules vacuuming dynamically in response to update activity. It is unwise to disable the daemon completely unless you @@ -227,8 +231,8 @@ a table contains large numbers of dead row versions as a result of massive update or delete activity. If you have such a table and you need to reclaim the excess disk space it occupies, you will need - to use VACUUM FULL, or alternatively - CLUSTER + to use REPACK, + CLUSTER or VACUUM FULL or one of the table-rewriting variants of ALTER TABLE. These commands rewrite an entire new copy of the table and build diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index f1422826d29..4e1770927d3 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -7443,8 +7443,8 @@ FROM pg_stat_get_backend_idset() AS backendid; command text - The command that is running. Either REPACK or - VACUUM FULL, or CLUSTER. + The command that is running. Either REPACK, + VACUUM FULL or CLUSTER. diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index 9cb52302f23..0e75e4f99a5 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -1093,12 +1093,14 @@ ERROR: could not serialize access due to read/write dependencies among transact - Acquired by the DROP TABLE, + Acquired by commands: DROP TABLE, TRUNCATE, REINDEX, CLUSTER, VACUUM FULL, - and REFRESH MATERIALIZED VIEW (without - ) - commands. Many forms of ALTER INDEX and ALTER TABLE also acquire + and more REPACK and + REFRESH MATERIALIZED VIEW, both without + . + Many forms of ALTER INDEX and + ALTER TABLE also acquire a lock at this level. This is also the default lock mode for LOCK TABLE statements that do not specify a mode explicitly. -- 2.51.2.windows.1