public inbox for [email protected]  

help / color / mirror / Atom feed

From: 'Alvaro Herrera' <[email protected]>
To: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Sat, 4 Apr 2026 12:19:10 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <OS9PR01MB121494749F57A32A17D73F4B1F55FA@OS9PR01MB12149.jpnprd01.prod.outlook.com>

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/[email protected]
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"

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Adding REPACK [concurrently]
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox