Re: Clarification on Role Access Rights to Table Indexes - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Clarification on Role Access Rights to Table Indexes
Date
Msg-id Z88CB-vDehJ9rW8u@nathan
Whole thread Raw
In response to Re: Clarification on Role Access Rights to Table Indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Mar 09, 2025 at 11:48:05AM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Sat, Mar 08, 2025 at 05:17:40PM -0500, Tom Lane wrote:
>>> ReindexIndex() faces this same problem and solves it with some
>>> very complex code that manages to get the table's lock first.
> 
>> I noticed that amcheck's bt_index_check_internal() handles this problem,
>> ...
>> stats_lock_check_privileges() does something similar, but it's not as
>> cautious about the "heapid != IndexGetRelation(indrelid, false)" race
>> condition.
> 
> Egad, we've already got three inconsistent implementations of this
> functionality?  I think the first step must be to unify them into
> a common implementation, if at all possible.

Agreed.  I worry that trying to unify each bespoke implementation into a
single function might result in an unwieldy mess, but I'll give it a
shot...

-- 
nathan



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: vacuumdb changes for stats import/export
Next
From: Tomas Vondra
Date:
Subject: Re: Changing the state of data checksums in a running cluster