MIME-Version: 1.0
References: 
 <OS9PR01MB121494749F57A32A17D73F4B1F55FA@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <202604040949.opyhm3tgddvt@alvherre.pgsql>
In-Reply-To: <202604040949.opyhm3tgddvt@alvherre.pgsql>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 6 Apr 2026 10:54:23 +0530
Message-ID: 
 <CAA4eK1Jwguq90CC8nxOqan+raCS8WisB=Bmb1AmK8rcvtj8GPg@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1Jwguq90CC8nxOqan%2BraCS8WisB%3DBmb1AmK8rcvtj8GPg%40mail.gmail.com>
Precedence: bulk

On Sat, Apr 4, 2026 at 3:49=E2=80=AFPM 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, n=
oticed 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 dat=
abase 5
> >         automatic vacuum of table "postgres.public.test"
> > ```
> >
> > The behavior is different from other commands, like LOCK and maybe norm=
al 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 ter=
minate 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.

--=20
With Regards,
Amit Kapila.