Re: Handle concurrent drop when doing whole database vacuum

Hello.

At Sun, 14 Jun 2026 15:12:43 +0800, "cca5507" <cca5507(at)qq(dot)com> 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