Correct some doc items due to the REPACK
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253256psql -h localhost -U postgresBuilt from patchset v2 (message #2), August 25, 2026 at 08:13 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253256_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253256_2 && git checkout t253256_2Patchset v2 (message #2) is on t253256_2
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
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
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
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
Does this one deserve a mention on the open items wiki [0]https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items?
[0]: https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
--
nathan
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
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
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 neededDid 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)
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