Horton
Menu

Re: Adding REPACK [concurrently]

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>, Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Robert Treat <rob@xzilla.net>
Date: 2026-04-01T11:42:17Z
Lists: pgsql-hackers 
On 2026-Apr-01, Amit Kapila wrote:

> BTW, is the reason to skip REPACK while building a snapshot is that it
> can take a long time to finish?

As I understand the issue, yes, that's precisely the problem: if you
have one REPACK running, then starting a second REPACK (which requires
building a new snapshot) would have to wait until the first REPACK is
over.  In other words, you wouldn't be able to have two repacks running
concurrently.  This sounds like a problematic requirement.  So having
snapbuild ignore REPACK is there to allow the second REPACK to work at
all.  But more generally,  *all* users of snapbuild would be prevented
from starting until REPACK is done; so if you have a very very large
table that takes a long time to repack, then everything would be blocked
behind it until it completes, which sounds extremely unpleasant.

So, if we're unable to get this particular patch in, we would have to
have a big fat warning in the docs, telling people to be careful about
other load if they choose to run concurrent repack -- it could have
serious consequences.  But on the other hand, it's better to *have* the
tool, even if it has problems, than not have it.  Keep in mind that
pg_repack and pg_squeeze also have all these problems/limitations (and
others), and still people use them.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow old WAL recycling during REPACK CONCURRENTLY

  2. Advance restart_lsn more eagerly in LogicalConfirmReceivedLocation

  3. Remove unnecessary signal handler change

  4. Improve REPACK (CONCURRENTLY) error messages some more

  5. Revert "Allow logical replication snapshots to be database-specific"

  6. Move REPACK (CONCURRENTLY) test out of stock regression tests

  7. REPACK: do not require REPLICATION or LOGIN

  8. Add missing initialization

  9. Simplify declaration of memcpy target

  10. Reserve replication slots specifically for REPACK

  11. doc: Add an example of REPACK (CONCURRENTLY)

  12. Allow logical replication snapshots to be database-specific

  13. Avoid different-size pointer-to-integer cast

  14. Fix valgrind failure

  15. Add CONCURRENTLY option to REPACK

  16. Rename cluster.c to repack.c (and corresponding .h)

  17. Allow index_create to suppress index_build progress reporting

  18. Make index_concurrently_create_copy more general

  19. Document the 'command' column of pg_stat_progress_repack

  20. Introduce the REPACK command

  21. Toggle logical decoding dynamically based on logical slot presence.

  22. Split vacuumdb to create vacuuming.c/h

  23. Remove ReorderBufferTupleBuf structure.

  24. Revert changes to CONCURRENTLY that "sped up" Xmin advance

  25. VACUUM: ignore indexing operations with CONCURRENTLY