Re: Adding REPACK [concurrently]

On 2026-Apr-06, Amit Kapila wrote:

> On Sat, Apr 4, 2026 at 3:49 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:

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

Okay. I implemented that now, and here it is. 0001 is as before; 0002
creates shared memory for repack and has autovacuum recheck each table
there before processing it.

Having implemented it, I'm not sure the resulting behavior is all that
different from before. I mean, the only difference is that the worker
is going to see the table listed in repack shmem and skip it; as opposed
to trying to lock it and be terminated by the deadlock detector one
second later, at which point it continues with the next table on its
list. So it's some wasted work to set up the autovac work, but nothing
more.

However, there's also the point Andres just made in [1] which basically
kills this idea. So I'm withdrawing this proposal. Still, having
written it, I thought it'd be better to get it archived.

[1] https://postgr.es/m/4n4q3preb3lgyhpzstebhux7b2aojhsw7gik4ivaznyggiezrs@lrznutssxlh2

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
“Cuando no hay humildad las personas se degradan” (A. Christie)