Re: predefined role(s) for VACUUM and ANALYZE - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: predefined role(s) for VACUUM and ANALYZE
Date
Msg-id 20220930192350.GA171832@nathanxps13
Whole thread Raw
In response to Re: predefined role(s) for VACUUM and ANALYZE  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: predefined role(s) for VACUUM and ANALYZE
List pgsql-hackers
On Wed, Sep 28, 2022 at 01:12:22PM -0700, Nathan Bossart wrote:
> On Wed, Sep 28, 2022 at 03:09:46PM -0400, Stephen Frost wrote:
>> The max is the same regardless of the size..?  Considering the size is
>> capped since pg_class doesn’t (and isn’t likely to..) have a toast table,
>> that seems unlikely, so I’m asking for clarification on that. We may be
>> able to get consensus that the difference isn’t material since no one is
>> likely to have such long lists, but we should at least be aware.
> 
> While pg_class doesn't have a TOAST table, that column is marked as
> "extended," so I believe it is still compressed, and the maximum aclitem
> array length for pg_class.relacl would depend on how well the array
> compresses.

Are there any remaining concerns about this approach?  I'm happy to do any
testing that folks deem necessary, or anything else really that might help
move this patch set forward.  If we don't want to extend AclMode right
away, we could also keep it in our back pocket for the next time someone
(which may very well be me) wants to add privileges.  That is, 0001 is not
fundamentally a prerequisite for 0002-0004, but I recognize that freeing up
some extra bits would be the most courteous.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Next
From: Tom Lane
Date:
Subject: Re: Question: test "aggregates" failed in 32-bit machine