Re: Handle concurrent drop when doing whole database vacuum

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