pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedCorrect some doc items due to the REPACK
9+ messages / 4 participants
[nested] [flat]
* Correct some doc items due to the REPACK
@ 2026-07-30 14:37 Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Marcos Pegoraro @ 2026-07-30 14:37 UTC (permalink / raw)
To: pgsql-hackers
Some sentences in the documentation have become strange or incomplete since
the REPACK command was added.
Some were not modified because they referred to variants of VACUUM, not
specifically about VACUUM FULL
regards
Marcos
Attachments:
[application/octet-stream] v1-0001 add missing doc since REPACK command.diff (6.4K, ../../CAB-JLwaLcHyf=OnLnBsJEbdd57WjWPpK5T7iGFJvAQphjTZj_A@mail.gmail.com/3-v1-0001%20add%20missing%20doc%20since%20REPACK%20command.diff)
download | inline diff:
From 6533c459706ab74b2206bb085ef1c9b800a8e656 Mon Sep 17 00:00:00 2001
From: PegoraroF10 <marcos@f10.com.br>
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 <structfield>ctid</structfield> can be used to
locate the row version very quickly, a row's
<structfield>ctid</structfield> will change if it is
- updated or moved by <command>VACUUM FULL</command>. Therefore
+ updated or moved by <command>REPACK</command>,
+ <command>CLUSTER</command> or <command>VACUUM FULL</command>. Therefore
<structfield>ctid</structfield> should not be used as a row
identifier. A primary key should be used to identify logical rows.
</para>
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, <command>VACUUM FULL</command> actively compacts
+ easily obtained. In contrast, <command>REPACK</command>,
+ <command>CLUSTER</command> or <command>VACUUM FULL</command> 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 <command>VACUUM FULL</command> can be used to shrink a table back
+ Although <command>REPACK</command>, <command>CLUSTER</command> or
+ <command>VACUUM FULL</command> 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 <command>VACUUM</command> runs are a
- better approach than infrequent <command>VACUUM FULL</command> runs for
+ better approach than infrequent <command>REPACK</command>,
+ <command>CLUSTER</command> or <command>VACUUM FULL</command> runs for
maintaining heavily-updated tables.
</para>
@@ -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 <command>VACUUM FULL</command> is really necessary
+ get bloated to the point that <command>REPACK</command>,
+ <command>CLUSTER</command> or <command>VACUUM FULL</command> 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 <command>VACUUM FULL</command>, or alternatively
- <link linkend="sql-cluster"><command>CLUSTER</command></link>
+ to use <command>REPACK</command>,
+ <command>CLUSTER</command> or <command>VACUUM FULL</command>
or one of the table-rewriting variants of
<link linkend="sql-altertable"><command>ALTER TABLE</command></link>.
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;
<structfield>command</structfield> <type>text</type>
</para>
<para>
- The command that is running. Either <command>REPACK</command> or
- <command>VACUUM FULL</command>, or <command>CLUSTER</command>.
+ The command that is running. Either <command>REPACK</command>,
+ <command>VACUUM FULL</command> or <command>CLUSTER</command>.
</para></entry>
</row>
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
</para>
<para>
- Acquired by the <command>DROP TABLE</command>,
+ Acquired by commands: <command>DROP TABLE</command>,
<command>TRUNCATE</command>, <command>REINDEX</command>,
<command>CLUSTER</command>, <command>VACUUM FULL</command>,
- and <command>REFRESH MATERIALIZED VIEW</command> (without
- <option>CONCURRENTLY</option>)
- commands. Many forms of <command>ALTER INDEX</command> and <command>ALTER TABLE</command> also acquire
+ and more <command>REPACK</command> and
+ <command>REFRESH MATERIALIZED VIEW</command>, both without
+ <option>CONCURRENTLY</option>.
+ Many forms of <command>ALTER INDEX</command> and
+ <command>ALTER TABLE</command> also acquire
a lock at this level. This is also the default lock mode for
<command>LOCK TABLE</command> statements that do not specify
a mode explicitly.
--
2.51.2.windows.1
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
@ 2026-08-13 07:45 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
0 siblings, 1 reply; 9+ messages in thread
From: Fujii Masao @ 2026-08-13 07:45 UTC (permalink / raw)
To: Marcos Pegoraro <marcos@f10.com.br>; +Cc: pgsql-hackers
On Thu, Jul 30, 2026 at 11:37 PM Marcos Pegoraro <marcos@f10.com.br> wrote:
>
> Some sentences in the documentation have become strange or incomplete since the REPACK command was added.
>
> Some were not modified because they referred to variants of VACUUM, not specifically about VACUUM FULL
Thanks for the patch! I agree that these docs updates are needed after
adding REPACK.
I updated the patch and attached v2.
Here are the main changes from v1:
- In ddl.sgml, v1 listed REPACK, CLUSTER, and VACUUM FULL directly in
the ctid description. Since other table-rewriting operations can also
change CTIDs, I changed this to describe them as examples using
"such as" rather than trying to enumerate them.
- In maintenance.sgml, v1 mixed REPACK and CLUSTER into text that was
mainly about routine VACUUM and VACUUM FULL. I reworded the relevant
sections to describe VACUUM FULL, CLUSTER, and REPACK as table-rewriting
compaction operations where appropriate. I also clarified the
ACCESS EXCLUSIVE locking behavior, including the special case of
REPACK CONCURRENTLY.
- In monitoring.sgml, v1 only updated the command list for
pg_stat_progress_repack. I also updated the surrounding text so that
the view consistently describes REPACK, CLUSTER, and VACUUM FULL, while
keeping pg_stat_progress_cluster described as the compatibility view.
- In mvcc.sgml, v1 added REPACK to the ACCESS EXCLUSIVE lock list in a
way that made the CONCURRENTLY behavior ambiguous. I changed this to
say that REPACK also acquires this lock mode, while REPACK CONCURRENTLY
acquires it only when swapping the table and index files.
I also made a few minor adjustments to links, wording, and whitespace.
Regards,
--
Fujii Masao
Attachments:
[application/octet-stream] v2-0001-doc-Update-REPACK-related-table-rewrite-documenta.patch (11.5K, ../../CAHGQGwGn6i-n8zrVg2BMJ19jbMM0O2wfv0ZEYa9R8Z6y747iAQ@mail.gmail.com/2-v2-0001-doc-Update-REPACK-related-table-rewrite-documenta.patch)
download | inline diff:
From d3bcc907cdbfdea63ee4a72d979674b445a83812 Mon Sep 17 00:00:00 2001
From: PegoraroF10 <marcos@f10.com.br>
Date: Thu, 30 Jul 2026 11:31:06 -0300
Subject: [PATCH v2] doc: Update REPACK-related table rewrite documentation
Adding REPACK introduced table-rewrite behavior that overlaps with
VACUUM FULL and CLUSTER, but some documentation still mentioned only one
of these commands or described the progress and locking behavior
imprecisely.
Clarify that table-rewriting operations, including REPACK, can change
CTIDs. Also describe VACUUM FULL, CLUSTER, and REPACK consistently as
table-rewriting operations for disk-space recovery where appropriate,
document the pg_stat_progress_repack and compatibility
pg_stat_progress_cluster views consistently, and clarify the ACCESS
EXCLUSIVE locking behavior of REPACK, including CONCURRENTLY.
Backpatch to v19, where REPACK was introduced.
---
doc/src/sgml/ddl.sgml | 4 +++-
doc/src/sgml/maintenance.sgml | 45 +++++++++++++++++++++--------------
doc/src/sgml/monitoring.sgml | 24 +++++++++++--------
doc/src/sgml/mvcc.sgml | 12 ++++++----
4 files changed, 52 insertions(+), 33 deletions(-)
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 9006b947e74..4ae6ff2d614 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1568,7 +1568,9 @@ CREATE TABLE circles (
although the <structfield>ctid</structfield> can be used to
locate the row version very quickly, a row's
<structfield>ctid</structfield> will change if it is
- updated or moved by <command>VACUUM FULL</command>. Therefore
+ updated, or moved by a table-rewriting operation such as
+ <command>VACUUM FULL</command>, <command>CLUSTER</command>, or
+ <command>REPACK</command>. Therefore
<structfield>ctid</structfield> should not be used as a row
identifier. A primary key should be used to identify logical rows.
</para>
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 33ab4edf87c..c0972b04212 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -171,11 +171,13 @@
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, <command>VACUUM FULL</command> 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
- the operation completes.
+ easily obtained. In contrast, table-rewriting commands such as
+ <command>VACUUM FULL</command>, <command>CLUSTER</command>, and
+ <command>REPACK</command> actively compact tables by writing a complete
+ new version of the table file without the dead space left by old row
+ versions. 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 the
+ operation completes.
</para>
<para>
@@ -186,12 +188,14 @@
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 <command>VACUUM FULL</command> 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 <command>VACUUM</command> runs are a
- better approach than infrequent <command>VACUUM FULL</command> runs for
- maintaining heavily-updated tables.
+ Although table-rewriting compaction operations such as
+ <command>VACUUM FULL</command>, <command>CLUSTER</command>, and
+ <command>REPACK</command> 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 <command>VACUUM</command> runs are a
+ better approach than infrequent use of such operations for maintaining
+ heavily-updated tables.
</para>
<para>
@@ -199,7 +203,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 <command>VACUUM FULL</command> is really necessary
+ get bloated to the point that a table-rewriting compaction operation such
+ as <command>VACUUM FULL</command> or <command>REPACK</command> may be needed
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,16 +232,20 @@
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 <command>VACUUM FULL</command>, or alternatively
- <link linkend="sql-cluster"><command>CLUSTER</command></link>
+ to use <command>VACUUM FULL</command>,
+ <link linkend="sql-cluster"><command>CLUSTER</command></link>,
+ <link linkend="sql-repack"><command>REPACK</command></link>,
or one of the table-rewriting variants of
<link linkend="sql-altertable"><command>ALTER TABLE</command></link>.
These commands rewrite an entire new copy of the table and build
new indexes for it. All these options require an
- <literal>ACCESS EXCLUSIVE</literal> lock. Note that
- they also temporarily use extra disk space approximately equal to the size
- of the table, since the old copies of the table and indexes can't be
- released until the new ones are complete.
+ <literal>ACCESS EXCLUSIVE</literal> lock, except that
+ <command>REPACK</command> can be run with <literal>CONCURRENTLY</literal>,
+ in which case the <literal>ACCESS EXCLUSIVE</literal> lock is held only
+ while swapping the table and index files. Note that they also
+ temporarily use extra disk space approximately equal to the size of the
+ table, since the old copies of the table and indexes can't be released
+ until the new ones are complete.
</para>
</tip>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 32cb6fdbd76..53d81ac63d1 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -417,7 +417,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_progress_repack</structname><indexterm><primary>pg_stat_progress_repack</primary></indexterm></entry>
<entry>One row for each backend running <command>REPACK</command>,
<command>CLUSTER</command> or <command>VACUUM FULL</command>, showing current progress.
- <xref linkend="repack-progress-reporting"/>.
+ See <xref linkend="repack-progress-reporting"/>.
</entry>
</row>
@@ -6726,7 +6726,8 @@ FROM pg_stat_get_backend_idset() AS backendid;
<command>VACUUM FULL</command> is running,
the backwards-compatibility <structname>pg_stat_progress_cluster</structname>
view will
- contain a row for each backend that is currently running either command.
+ contain a row for each backend that is currently running one of these
+ commands.
The tables below describe the information that will be reported and
provide information about how to interpret it.
</para>
@@ -7400,10 +7401,11 @@ FROM pg_stat_get_backend_idset() AS backendid;
</indexterm>
<para>
- Whenever <command>REPACK</command> is running,
+ Whenever <command>REPACK</command>, <command>CLUSTER</command>, or
+ <command>VACUUM FULL</command> is running,
the <structname>pg_stat_progress_repack</structname> view will contain a
- row for each backend that is currently running the command. The tables
- below describe the information that will be reported and provide
+ row for each backend that is currently running one of these commands.
+ The tables below describe the information that will be reported and provide
information about how to interpret it.
</para>
@@ -7454,7 +7456,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
- OID of the table being repacked.
+ OID of the table being processed.
</para></entry>
</row>
@@ -7463,8 +7465,8 @@ FROM pg_stat_get_backend_idset() AS backendid;
<structfield>command</structfield> <type>text</type>
</para>
<para>
- The command that is running. Either <command>REPACK</command> or
- <command>VACUUM FULL</command>, or <command>CLUSTER</command>.
+ The command that is running. One of <command>CLUSTER</command>,
+ <command>REPACK</command>, or <command>VACUUM FULL</command>.
</para></entry>
</row>
@@ -7657,10 +7659,12 @@ FROM pg_stat_get_backend_idset() AS backendid;
currently vacuuming. The tables below describe the information
that will be reported and provide information about how to interpret it.
Progress for <command>VACUUM FULL</command> commands is reported via
- <structname>pg_stat_progress_cluster</structname>
+ <structname>pg_stat_progress_repack</structname>, and is also visible via
+ the backwards-compatibility <structname>pg_stat_progress_cluster</structname>
because both <command>VACUUM FULL</command> and <command>CLUSTER</command>
rewrite the table, while regular <command>VACUUM</command> only modifies it
- in place. See <xref linkend="cluster-progress-reporting"/>.
+ in place. See <xref linkend="repack-progress-reporting"/> and
+ <xref linkend="cluster-progress-reporting"/>.
</para>
<table id="pg-stat-progress-vacuum-view" xreflabel="pg_stat_progress_vacuum">
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 9cb52302f23..ff01e97ea3d 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1095,10 +1095,14 @@ ERROR: could not serialize access due to read/write dependencies among transact
<para>
Acquired by the <command>DROP TABLE</command>,
<command>TRUNCATE</command>, <command>REINDEX</command>,
- <command>CLUSTER</command>, <command>VACUUM FULL</command>,
- and <command>REFRESH MATERIALIZED VIEW</command> (without
- <option>CONCURRENTLY</option>)
- commands. Many forms of <command>ALTER INDEX</command> and <command>ALTER TABLE</command> also acquire
+ <command>CLUSTER</command>, <command>VACUUM FULL</command>, and
+ <command>REFRESH MATERIALIZED VIEW</command> (without
+ <option>CONCURRENTLY</option>) commands.
+ <command>REPACK</command> also acquires this lock mode. When run
+ with <option>CONCURRENTLY</option>, <command>REPACK</command> acquires
+ it only while swapping the table and index files.
+ Many forms of <command>ALTER INDEX</command> and
+ <command>ALTER TABLE</command> also acquire
a lock at this level. This is also the default lock mode for
<command>LOCK TABLE</command> statements that do not specify
a mode explicitly.
--
2.55.0
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
@ 2026-08-13 14:50 ` Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Marcos Pegoraro @ 2026-08-13 14:50 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: pgsql-hackers
Em qui., 13 de ago. de 2026 às 04:45, Fujii Masao <masao.fujii@gmail.com>
escreveu:
> - In mvcc.sgml, v1 added REPACK to the ACCESS EXCLUSIVE lock list in a
> way that made the CONCURRENTLY behavior ambiguous. I changed this to
> say that REPACK also acquires this lock mode, while REPACK CONCURRENTLY
> acquires it only when swapping the table and index files.
Cool, your version is much better than mine.
Only on mvcc.sgml I think mine is better because explains other commands
and both which have CONCURRENTLY option explained only once.
regards
Marcos
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
@ 2026-08-17 09:53 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-25 19:52 ` Re: Correct some doc items due to the REPACK Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Fujii Masao @ 2026-08-17 09:53 UTC (permalink / raw)
To: Marcos Pegoraro <marcos@f10.com.br>; +Cc: pgsql-hackers
On Thu, Aug 13, 2026 at 11:51 PM Marcos Pegoraro <marcos@f10.com.br> wrote:
> Cool, your version is much better than mine.
Thanks for the review!
> Only on mvcc.sgml I think mine is better because explains other commands and both which have CONCURRENTLY option explained only once.
The wording in v1 could be read as saying that REPACK CONCURRENTLY
never takes an ACCESS EXCLUSIVE lock. However, as described in the
REPACK docs, it still takes an ACCESS EXCLUSIVE lock while swapping
the table and index files. So I think v2 is more accurate.
I agree that it would be nice to explain the CONCURRENTLY cases only once,
but REPACK CONCURRENTLY differs from REFRESH MATERIALIZED VIEW CONCURRENTLY
in that it does take an ACCESS EXCLUSIVE lock.
Thoughts?
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
@ 2026-08-25 19:52 ` Nathan Bossart <nathandbossart@gmail.com>
2026-08-26 01:44 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Nathan Bossart @ 2026-08-25 19:52 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: Marcos Pegoraro <marcos@f10.com.br>; pgsql-hackers
Does this one deserve a mention on the open items wiki [0]?
[0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
--
nathan
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-25 19:52 ` Re: Correct some doc items due to the REPACK Nathan Bossart <nathandbossart@gmail.com>
@ 2026-08-26 01:44 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-26 14:42 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
0 siblings, 1 reply; 9+ messages in thread
From: Fujii Masao @ 2026-08-26 01:44 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Marcos Pegoraro <marcos@f10.com.br>; pgsql-hackers
On Wed, Aug 26, 2026 at 4:52 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> Does this one deserve a mention on the open items wiki [0]?
Since I don't think we should leave the patch pending for too long,
I've pushed it. Thanks!
Marcos, if you think there are still docs that need to be updated,
let's keep discussing them!
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-25 19:52 ` Re: Correct some doc items due to the REPACK Nathan Bossart <nathandbossart@gmail.com>
2026-08-26 01:44 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
@ 2026-08-26 14:42 ` Marcos Pegoraro <marcos@f10.com.br>
2026-09-21 11:23 ` Re: Correct some doc items due to the REPACK Álvaro Herrera <alvherre@kurilemu.de>
0 siblings, 1 reply; 9+ messages in thread
From: Marcos Pegoraro @ 2026-08-26 14:42 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; pgsql-hackers
Em ter., 25 de ago. de 2026 às 22:45, Fujii Masao <masao.fujii@gmail.com>
escreveu:
> I've pushed it. Thanks.
Great you've committed. But there are still two things pending, in my
opinion.
monitoring.sgml
The command that is running. One of <command>CLUSTER</command>,
<command>REPACK</command>, or <command>VACUUM FULL</command>.
should remove comma before or, so would be
The command that is running. One of <command>CLUSTER</command>,
<command>REPACK</command> or <command>VACUUM FULL</command>.
maintenance.sgml
get bloated to the point that a table-rewriting compaction operation such
as <command>VACUUM FULL</command> or <command>REPACK</command> may be needed
Did you forget CLUSTER here ?
regards
Marcos
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-25 19:52 ` Re: Correct some doc items due to the REPACK Nathan Bossart <nathandbossart@gmail.com>
2026-08-26 01:44 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-26 14:42 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
@ 2026-09-21 11:23 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-09-21 12:11 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
0 siblings, 1 reply; 9+ messages in thread
From: Álvaro Herrera @ 2026-09-21 11:23 UTC (permalink / raw)
To: Marcos Pegoraro <marcos@f10.com.br>; +Cc: Fujii Masao <masao.fujii@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; pgsql-hackers
For closure:
On 2026-Aug-26, Marcos Pegoraro wrote:
> monitoring.sgml
> The command that is running. One of <command>CLUSTER</command>,
> <command>REPACK</command>, or <command>VACUUM FULL</command>.
>
> should remove comma before or,
That with the commas is the style we use everywhere. These are called
"Oxford commas."
> maintenance.sgml
> get bloated to the point that a table-rewriting compaction operation such
> as <command>VACUUM FULL</command> or <command>REPACK</command> may be needed
>
> Did you forget CLUSTER here ?
I don't think mentioning CLUSTER improves things significantly here, as
that command's main purpose is not to remove bloat.
Thanks!
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Correct some doc items due to the REPACK
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-25 19:52 ` Re: Correct some doc items due to the REPACK Nathan Bossart <nathandbossart@gmail.com>
2026-08-26 01:44 ` Re: Correct some doc items due to the REPACK Fujii Masao <masao.fujii@gmail.com>
2026-08-26 14:42 ` Re: Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-09-21 11:23 ` Re: Correct some doc items due to the REPACK Álvaro Herrera <alvherre@kurilemu.de>
@ 2026-09-21 12:11 ` Marcos Pegoraro <marcos@f10.com.br>
0 siblings, 0 replies; 9+ messages in thread
From: Marcos Pegoraro @ 2026-09-21 12:11 UTC (permalink / raw)
To: Álvaro Herrera <alvherre@kurilemu.de>; +Cc: Fujii Masao <masao.fujii@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; pgsql-hackers
Em seg., 21 de set. de 2026 às 08:30, Álvaro Herrera <alvherre@kurilemu.de>
escreveu:
> That with the commas is the style we use everywhere. These are called
> "Oxford commas."
Thank you for the explanation.
But even though it's correct in English, this pattern of using a comma
followed by an 'and' is incorrect in most other languages.
And many people who read the documentation and see a comma followed by an
'and' think that an item is missing from the list.
So, if it's possible to write in English in a way that the rest of the
world understands, why not ?
regards
Marcos
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2026-09-21 12:11 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-30 14:37 Correct some doc items due to the REPACK Marcos Pegoraro <marcos@f10.com.br>
2026-08-13 07:45 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-13 14:50 ` Marcos Pegoraro <marcos@f10.com.br>
2026-08-17 09:53 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-25 19:52 ` Nathan Bossart <nathandbossart@gmail.com>
2026-08-26 01:44 ` Fujii Masao <masao.fujii@gmail.com>
2026-08-26 14:42 ` Marcos Pegoraro <marcos@f10.com.br>
2026-09-21 11:23 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-09-21 12:11 ` Marcos Pegoraro <marcos@f10.com.br>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox