Re: Handle concurrent drop when doing whole database vacuum

From: cca5507 <cca5507(at)qq(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, michael <michael(at)paquier(dot)xyz>
Cc: bharath(dot)rupireddyforpostgres <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, 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-26 09:36:36
Message-ID: tencent_76660EEFFE00C04E29D4A3D0AC9638854E05@qq.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> > FWIW, even after sleeping on it, I don't think that this patch is
> > going in the right direction.  I am pretty sure that we should just
> > lift the ACL check in get_all_vacuum_rels() and always require
> > vacuum_is_permitted_for_relation() to have the relation locked when
> > called.  This way we would rely on one single code path for the ACL
> > check, even if it means holding a reference of a relation OID for
> > something to be processsed later.  So I would revisit the choice made
>
> FWIW, I agree with this direction.

This direction is also OK for me. We might want to fix get_tables_to_repack()
together?

--
Regards,
ChangAo Chen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-06-26 09:42:52 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Vitaly Davydov 2026-06-26 09:31:27 Re: Deadlock detector fails to activate on a hot standby replica