Re: Handle concurrent drop when doing whole database vacuum

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