Re: Adding REPACK [concurrently]

Hello,

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.

Do you think it would be better if we allowed autovacuum to continue?
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.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Para tener más hay que desear menos"