Re: Adding REPACK [concurrently]

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

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Antonin Houska <ah@cybertec.at>
Cc: Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Mihail Nikalayeu <mihailnikalayeu@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-03T19:31:48Z
Lists: pgsql-hackers

Attachments

On 2026-Apr-03, Alvaro Herrera wrote:

> - I polished the patch to reserve replication slots for REPACK.  Given
>   the new implementation of 0006 that was submitted implies that we can
>   now run multiple repacks concurrently, I changed the default of 1 to 5.

Srinath let me know that this new part was causing CI failures on
Windows.  This version v51 should be okay (or, at least, it passes for
me on CI).  Additional changes worth mentioning:

- I think it's nicer for the index_create() API to get a bit to indicate
  suppression of progress reporting; so existing callers don't need to
  do anything.  I guess this is mostly a matter of taste.

- I incorporated Srinath's fix for the PreventInTransactionBlock block.

- When CheckSlotRequirements() is to complain about
  "max_replication_slots or max_repack_replication_slots", it seems
  actually nicer to say exactly which one of these is the cause of the
  problem.  This is easy to change; patch 0010 does it; it requires
  passing down a "repack" flag all the way from
  CheckLogicalDecodingRequirements() and it needs to add an argument to
  CreateInitDecodingContext(), which is perhaps not so great.  On the
  whole I'm inclined to do it anyway, but I'm about equally happy to
  leave it alone.  This is what would change:

original:
        ereport(ERROR,
-               (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
-                errmsg("replication slots can only be used if \"%s\" > 0 or \"%s\" > 0",
-                       "max_replication_slots", "max_repack_replication_slots")));

patched:
        ereport(ERROR,
+               errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+               errmsg("replication slots can only be used if \"%s\" > 0",
+                      repack ? "max_repack_replication_slots" : "max_replication_slots"));

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"This is a foot just waiting to be shot"                (Andrew Dunstan)

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