MIME-Version: 1.0
References: 
 <CAA4eK1+CNiuphtE=wwExsHD_McmYtGp2XK4qwX146VqRbgXmbA@mail.gmail.com>
 <202604011042.zdevjay65ws7@alvherre.pgsql>
In-Reply-To: <202604011042.zdevjay65ws7@alvherre.pgsql>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Wed, 1 Apr 2026 18:05:01 +0530
Message-ID: 
 <CAA4eK1+wbLEefXE+TuE6=C183Z0LT1oXSPcu-RUHYrL+WdAspQ@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Antonin Houska <ah@cybertec.at>,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
	Srinath Reddy Sadipiralla <srinath2133@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/CAA4eK1%2BwbLEefXE%2BTuE6%3DC183Z0LT1oXSPcu-RUHYrL%2BWdAspQ%40mail.gmail.com>
Precedence: bulk

On Wed, Apr 1, 2026 at 5:12=E2=80=AFPM Alvaro Herrera <alvherre@alvh.no-ip.=
org> wrote:
>
> On 2026-Apr-01, Amit Kapila wrote:
>
> > BTW, is the reason to skip REPACK while building a snapshot is that it
> > can take a long time to finish?
>
> As I understand the issue, yes, that's precisely the problem: if you
> have one REPACK running, then starting a second REPACK (which requires
> building a new snapshot) would have to wait until the first REPACK is
> over.  In other words, you wouldn't be able to have two repacks running
> concurrently.  This sounds like a problematic requirement.  So having
> snapbuild ignore REPACK is there to allow the second REPACK to work at
> all.  But more generally,  *all* users of snapbuild would be prevented
> from starting until REPACK is done; so if you have a very very large
> table that takes a long time to repack, then everything would be blocked
> behind it until it completes, which sounds extremely unpleasant.
>
> So, if we're unable to get this particular patch in, we would have to
> have a big fat warning in the docs, telling people to be careful about
> other load if they choose to run concurrent repack -- it could have
> serious consequences.
>

Right, I think during this time logical workers will keep timing out
and restarting without any progress because during this wait, we won't
be sending keep_alive messages.

--=20
With Regards,
Amit Kapila.