Re: Adding REPACK [concurrently]

On Wed, Apr 1, 2026 at 5:12 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

--
With Regards,
Amit Kapila.