Hi Kyotaro, > > 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.
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(). -- Regards, ChangAo Chen
