| From: | cca5507 <cca5507(at)qq(dot)com> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, michael <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, suryapoondla4 <suryapoondla4(at)gmail(dot)com> |
| Subject: | Re: Handle concurrent drop when doing whole database vacuum |
| Date: | 2026-06-27 08:19:11 |
| Message-ID: | tencent_515EB50C2919321578C207247632A1218508@qq.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
> I had a quick look at the repack code and it seems like it can also
> run into the same problem because repack_is_permitted_for_relation
> uses the same pg_class_aclcheck while building the tables list without
> holding locks, and later it rechecks permissions after the table locks
> in cluster_rel_recheck anyway. A simple fix there would be to just use
> pg_class_aclcheck_ext in repack_is_permitted_for_relation. I recommend
> discussing this in a separate thread CC-ing the repack authors to get
> agreement.
Note that we call ConditionalLockRelationOid() in get_tables_to_repack(),
which is an unexpected behavior I think. I have reported this issue in this
thread:
https://www.postgresql.org/message-id/flat/tencent_9F290B256A3F52B66542F1140E32ECC64309%40qq.com
> Do you mind sharing the vacuum-related fix where we have agreement in
> this thread? Thank you!
Please see the v5 patch.
--
Regards,
ChangAo Chen
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Do-not-check-permissions-in-get_all_vacuum_rels.patch | application/octet-stream | 1.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-06-27 08:54:59 | Re: Add tests for concurrent DML retry paths in logical replication apply |
| Previous Message | Shinya Kato | 2026-06-27 08:08:02 | Re: Report oldest xmin source when autovacuum cannot remove tuples |