Horton
Menu

Re: Adding REPACK [concurrently]

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Antonin Houska <ah@cybertec.at>, Srinath Reddy Sadipiralla <srinath2133@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-06T05:24:23Z
Lists: pgsql-hackers 
On Sat, Apr 4, 2026 at 3:49 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2026-Apr-04, Hayato Kuroda (Fujitsu) wrote:
>
> > While testing REPACK CONCURRENTLY command with xid_wraparound module, noticed that
> > wraparound-autovac worker was terminated with an error like below.
> >
> > ``
> > ERROR:  could not wait for concurrent REPACK
> > DETAIL:  Process 41512 waits for REPACK running on process 41027
> > CONTEXT:  waiting for ShareUpdateExclusiveLock on relation 16384 of database 5
> >         automatic vacuum of table "postgres.public.test"
> > ```
> >
> > The behavior is different from other commands, like LOCK and maybe normal REPACK.
> > In these cases the autovac worker would wait till the command fails.
> >
> > Is it an intentional behavior? If so, what is the advantage that we terminate the
> > failsafe vacuum?
>
> Hmm, this is intentional; see here:
> https://postgr.es/m/202604011050.7ya3k4ccd3hg@alvherre.pgsql
> Note that in order for this to happen, the autovacuum must be starting
> when the repack is already underway.  The theory behind this behavior is
> that the autovacuum run is not useful anyway: its purpose is to advance
> the freeze xmin/multixact, but the repack is also going to do that.
> Once repack is done, autovacuum can assess again whether an emergency
> vacuum is needed, and launch a worker in that case.
>

But won't it delay in update of datfrozenxid/datminmxid? For example,
say repack errored out due to some reason, won't it further delay the
update to datfrozenxid/datminmxid which in turn can delay truncate of
clog. Is it possible that after repack errored out the launcher delays
in picking the same table again which further add to such a delay?

> Do you think it would be better if we allowed autovacuum to continue?
>

IIUC, the disadvantage of letting it continue is that if repack is
successful then we have unnecessarily occupied the worker which won't
do anything useful. If we want to not let autovacuum continue then we
should somehow deal with boundary cases which shouldn't lead to delay
in making progress to update frozen xids.

> I'm not 100% myself of this new behavior, and it would be very good to
> give it some more thought.
>
>
> I suppose it's unfortunate that autovacuum launcher is going to try
> again and again to get workers to process that table, and they are going
> to be killed over and over.  Maybe it would be better to have autovac
> ignore those tables.
>

I feel that would be better at least when we know that the repack
concurrently command is already in progress. It can help avoid
launching workers again and again, especially when repack concurrently
command is going to take a long time.

-- 
With Regards,
Amit Kapila.

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