Hi, On Tue, Jun 23, 2026 at 4:14 PM Michael Paquier <[email protected]> wrote: > > 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.
Spot on. My thinking was along similar lines. I'm concerned that in the worst case - where the role running a database-wide vacuum has no MAINTAIN privilege at all, or has it on only a small subset of tables - this approach will unnecessarily do a bunch of memory allocations, start a transaction, get a snapshot, commit the transaction, and acquire/release locks for each relation. So, IMHO, -1 for this approach. Instead, I would prefer using the pg_class_aclcheck_ext check and just emitting a WARNING (like the other skipping messages) when the relation is concurrently dropped. That said, I'm open to hearing from others. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
