On Mon, Jun 29, 2026 at 11:54:44AM -0500, Nathan Bossart wrote: > I'm mostly concerned about reopening the ability for folks to take strong > locks on catalogs without the necessary privileges, even if they are only > briefly held. Commit a556549 fixed a real problem, so I'm nervous about > partially reverting it. IOW my first reaction is that v1 is the right > idea, i.e., we should just skip the relation if it disappears. I'm not > sure we even need to log it.
I have finally spent some time with my head down on this problem. This would be an issue when a role issues a database-wide VACUUM but lacks grant access to a table it may look at when opening the relation. Simple example, two sessions with this setup: create role popo login; create table vacuum_tab (a int); -- owner is my superuser 1) session 1: superuser role BEGIN; LOCK vacuum_tab; 2) session 2: user popo -- Allowed to run, and all relations should be skipped. VACUUM; And unfortunately, my intuition and memories were wrong. If we simply remove the early ACL check when the list of relations is built, the system-wide VACUUM would block when trying to open the relation vacuum_tab, meaning that lock attempts would stack, and that's what a556549d7e6d is all about: the VACUUM should run, and skip all relations. Keeping the early ACL check and switching to _ext() would keep the safeguard in place when running a database-wide VACUUM, and address the concurrent drop issue. The suggestion of not logging that the relation is gone while checking its ACL while we don't hold a lock on the relation feels OK here. Something that still feels off to me is to blindly use _ext() in vacuum_is_permitted_for_relation(), where we *may* already hold a lock on the relation whose ACL is checked. In this case missing a relation is not fine, so this would make the code more brittle in the single-relation case under autovacuum or a VACUUM with a list of relations provided by a user. -- Michael
signature.asc
Description: PGP signature
