Re: Adding REPACK [concurrently]

Hello, Andres!

On Wed, Apr 8, 2026 at 7:22 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think this is a viable path. You need to prevent any further lock
> acquisitions on the relation to be able to swap it, not just conflicting DDL.

AFAIU, Amit's main idea is that we currently upgrade the lock instead
of **releasing and re-acquiring** it because we fear DDL between those
actions.
DML actions are ok for us; REPACK will wait for them while getting
AEL. Later changes will be applied by REPACK backend while holding
AEL.

One more thing we may prevent from sneaking into that hole is a
VACUUM. It will not break anything, but will be huge waste of time and
resources.

> And you need to wait for all pre-existing locks to have been released. That
> doesn't really get easier by what you propose.

Do you mean locks from other sessions accessing the table? Is it done
automatically while waiting for AEL?

> I don't think CheckTableNotInUse() would work anyway - don't we already hold
> locks by the point we call it?

Yes, the DDL session already holds locks by the time
CheckTableNotInUse is called - but is that really the problem? They
will be released on error.

> And even if that were not the case, there are
> several paths to locking relations that don't ever go anywhere near
> CheckTableNotInUse().

But those aren't DDL, so they shouldn't be the problem (CREATE TRIGGER
might be - it seems to ignore CheckTableNotInUse, but perhaps it's
fine).

So, in my undeerstanding Amit's idea has two parts: "set flag and
release/re-acquire" + "use CheckTableNotInUse (or some place like
that) to check the flag and fail for DDL commands."

Reading your arguments again, they all seem valid under the assumption
that we still hold SUEL while requesting AEL.
I suspect you may have just skimmed past the 'release/re-acquire' part
- but more probably I missed something.

Best regards,
Mikhail.