Hello, Andres! On Wed, Apr 8, 2026 at 7:22 PM Andres Freund <[email protected]> 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.
