| 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 |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Chao Li | 2026-06-16 07:20:19 | Re: pg_restore handles extended statistics inconsistently with statistics data |