Do not lock tables in get_tables_to_repack

From: cca5507 <cca5507(at)qq(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Do not lock tables in get_tables_to_repack
Date: 2026-06-16 07:34:55
Message-ID: tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Regards,
ChangAo Chen

Attachment Content-Type Size
v1-0001-Do-not-lock-tables-in-get_tables_to_repack.patch application/octet-stream 5.4 KB

Browse pgsql-hackers by date

  From Date Subject
Previous Message Chao Li 2026-06-16 07:20:19 Re: pg_restore handles extended statistics inconsistently with statistics data