Hello. At Sun, 14 Jun 2026 15:12:43 +0800, "cca5507" <[email protected]> wrote in > When doing a whole database vacuum, we scan pg_class to construct > a list of vacuumable tables. For each vacuumable table, we call > vacuum_is_permitted_for_relation() to check permissions. If a > concurrent drop happens, the pg_class_aclcheck() might report an > error because of failing to search the syscache: > > ERROR: relation with OID ****** does not exist
Good catch! > To fix it, we can use pg_class_aclcheck_ext() to detect the concurrent > drop and report a warning instead. Another possible direction might be to take a lock when building the list, instead of dealing with the race later. For example, the repack command seems to take a light lock when it finds a candidate relation: static List * get_tables_to_repack(RepackCommand cmd, bool usingindex, MemoryContext permcxt) > /* > * Try to obtain a light lock on the table, to ensure it doesn't > * go away while we collect the list. If we cannot, just > * disregard the table. Be sure to release this if we ultimately > * decide not to process the table! > */ > if (!ConditionalLockRelationOid(class->oid, AccessShareLock)) > continue; 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. Regards, -- Kyotaro Horiguchi NTT Open Source Software Center
