Re: Adding REPACK [concurrently]

Antonin Houska <ah@cybertec.at>

From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Andres Freund <andres@anarazel.de>, Amit Kapila <amit.kapila16@gmail.com>, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, pgsql-hackers@lists.postgresql.org, Robert Treat <rob@xzilla.net>
Date: 2026-04-20T13:46:13Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> On 2026-Apr-20, Antonin Houska wrote:
> 
> > Antonin Houska <ah@cybertec.at> wrote:
> > 
> > > It was discussed earlier [1] and the concerns about possibly excessive
> > > resource consumptions were addressed by [2]. So I think it the fix was just
> > > forgotten. Attached here.
> > 
> > Sorry, I attached wrong patch. This is what I meant.
> 
> Yeah, I had also written the same patch a couple of days ago.
> 
> BTW I ran into a small problem after adding some tests in cluster.sql
> that would exercise this -- that test would die more or less randomly
> but frequently in CI (which it never did in my laptop) because of the
> size of the snapshot,
> 
>  ALTER TABLE ptnowner1 REPLICA IDENTITY USING INDEX ptnowner1_i_key;
>  REPACK (CONCURRENTLY) ptnowner1;
> +ERROR:  initial slot snapshot too large
> +CONTEXT:  REPACK decoding worker
>  RESET SESSION AUTHORIZATION;
> 
> I think the solution for this is to move cluster to a separate parallel
> test.  The one where it is now is a bit too crowded.  Maybe the one for
> compression is okay?  I'll test and push if I see it passing CI.

That shouldn't break anything, but I have no idea why this problem was not
triggered (as far as I remember) by the stress tests we ran during
development.

I thought that it might be due to less frequent calls of
SnapBuildPurgeOlderTxn(), which might in turn be due to less frequent
checkpoints (because xl_running_xacts is typically written during checkpoint),
and that checkpoints may be deliberately less frequent to make regression
tests run faster. However I don't immediately see related configuration in the
regression test setup.

> Another obvious thing after adding tests is that the LOGIN privilege is
> required, which is also quite bogus IMO.  0002 here should solve that.

ok

> >From b3d4158356f4914d2b0cba86eef6994c0ee50ab9 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=C3=81lvaro=20Herrera?= <alvherre@kurilemu.de>
> Date: Mon, 20 Apr 2026 11:38:48 +0200
> Subject: [PATCH 1/2] REPACK: do not require the user to have REPLICATION

> Because there are now successful concurrent repack runs in the
> regression tests, we're forced to run test_plan_advice under
> wal_level=replica.

Is this an attempt to disable REPACK (CONCURRENTLY)? That would require
wal_level=minimal (due to commit 67c20979ce). In which way does REPACK seem to
break test_plan_advice?

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.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