Re: predefined role(s) for VACUUM and ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Date: 2022-09-30 20:15:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> 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.

In view of the recent mess around bigint relfilenodes, it seems to me
that we shouldn't move forward with widening AclMode unless somebody
runs down which structs will get wider (or more aligned) and how much
that'll cost us. Maybe it's not a problem, but it could do with an
explicit look at the point.

I do agree with the position that these features are not where to
spend our last remaining privilege bits.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-09-30 20:34:32 Re: allowing for control over SET ROLE
Previous Message Tom Lane 2022-09-30 19:40:02 Re: Question: test "aggregates" failed in 32-bit machine