Re: Do not lock tables in get_tables_to_repack

Hi,

On Tue, Jun 16, 2026 at 12:35 AM cca5507 <cca5507(at)qq(dot)com> wrote:
>
> Hi hackers,
>
> When doing a whole database repack, we build a list of repackable
> tables and take a lock on them to prevent concurrent drops. But
> concurrent drops can always happen after we build the list because
> we process each table in a separate transaction. The
> ConditionalLockRelationOid() also makes the default behavior like
> SKIP_LOCKED, which is unexpected.
>
> To remove the locks, we need to make repack_is_permitted_for_relation()
> handles concurrent drops correctly: it should not report an error
> when failing to search the syscache in pg_class_aclcheck(). Use
> pg_class_aclcheck_ext() instead to detect a concurrent drop. Also
> check the return value of get_rel_name().
>
> Thoughts?

I don't have a strong opinion on fixing this for REPACK. For vacuum,
we wanted to get consistent behavior across all modes of invoking it
[1]. Whether to handle concurrent drops for REPACK depends on how long
it spends scanning pg_index/pg_class in get_tables_to_repack. Also,
vacuum is more commonly run database-wide (against all tables), and
without field experience showing this is a real problem for REPACK,
I'm not sure the fix is needed. That said, others may have a different
take - adding the REPACK authors here for their input.

[1] https://www.postgresql.org/message-id/CALj2ACUbhDFJWSwiyoUxXED2S2fr9Xis%3D08Rnjq53UzBE4FvzA%40mail.gmail.com

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com