Horton
Menu

Re: Adding REPACK [concurrently]

Antonin Houska <ah@cybertec.at>

View thread
From: Antonin Houska <ah@cybertec.at>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: alvherre@alvh.no-ip.org, Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Robert Treat <rob@xzilla.net>
Date: 2026-03-20T18:06:10Z
Lists: pgsql-hackers 
Antonin Houska <ah@cybertec.at> wrote:

> Antonin Houska <ah@cybertec.at> wrote:
> 
> > Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:
> > 
> > > The concurrency test failed once. I tried to reproduce the below scenario
> > > but no luck,i think the reason the assert failure happened because
> > > after speculative insert there might be no spec CONFIRM or ABORT, thoughts?
> > 
> > Perhaps, I'll try. I'm not sure the REPACK decoding worker does anthing
> > special regarding decoding. If you happen to see the problem again, please try
> > to preserve the related WAL segments - if this is a bug in PG executor,
> > pg_waldump might reveal that.
> 
> I could not reproduce the failure, and have no idea how speculative insert can
> stay w/o CONFIRM / ABORT record. The only problem I could imagine is that
> change_useless_for_repack() filters out the CONFIRM / ABORT record
> accidentally, but neither code review nor debugger proves that
> theory. (Actually if this was the problem, the test failure probably wouldn't
> be that rare.)

I confirm that I was able to reproduce the crash using debugger and your more
recent diagnosis [1]. Indeed, filtering was the problem.

Unfortunately, I wasn't able to make the crash easily reproducible using
isolation tester. The problem is that the logical decoding is performed by a
background worker, and when the backend executing REPACK waits for the
background worker, which in turn waits on an injection point, the isolation
tester does not recognize that it's effectively the backend who is waiting on
the injection point. Therefore the isolation tester does not proceed to the
next step.

Anyway, thanks again for your testing!

[1] https://www.postgresql.org/message-id/CAFC%2Bb6qk3-DQTi43QMqvVLP%2BsudPV4vsLQm5iHfcCeObrNaVyA%40mail.gmail.com

-- 
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