On Mon, Jun 15, 2026 at 02:29:57PM +0800, cca5507 wrote: >> Whether a relation that disappears immediately after being added to >> the list should be processed or skipped does not seem particularly >> important in practice. However, taking a lock at list construction >> time may make the subsequent processing simpler. I wonder whether that >> would be a reasonable direction for VACUUM as well. > > I don't think it's a good idea because there might be a lot of tables need > to be locked. And a concurrent drop can always happen after the list > construction because we process each table in a separate transaction. > So I think there is no need to prevent concurrent drops at list construction > time. I also prepare to write a patch to remove the lock in > get_tables_to_repack().
Yeah, I doubt that forcing a lock an extra lock at an early stage is a good thing for a manual VACUUM. Anyway, I am wondering if we should aim for simpler. Do we really need the extra ACL check when building a list of relations to consider for a manual VACUUM in the pg_class scan? We are going to re-check the permissions once we vacuum each relation in its own transaction, *after* taking a lock on them, making the ACL check safe. That's the vacuum_open_relation()->vacuum_is_permitted_* flow. On a database with many relations where there is no MAINTAIN privilege for the role running the manual VACUUM, it means more transaction overhead because more transactions would need to be created for each relation whose ACLs need to be rechecked, because we don't filter the relations beforehand with the initial pg_class scan, but that would protect from the concurrent drops entirely by limitting the check to be in *one* path: the one analyzing or vacuuming a single relation. I am not saying that any of this should be backpatched and that we should treat this as a bug, a concurrent DROP reflecting on a database-wide VACUUM is annoying, but that's not really a critical thing to deal with. Improving that on HEAD sounds fine to me (not v19). -- Michael
signature.asc
Description: PGP signature
