On Tue, Dec 06, 2022 at 11:47:50AM +, Dagfinn Ilmari Mannsåker wrote:
> These checks are getting rather repetitive, how about a data-driven
> approach, along the lines of the below patch? I'm not quite happy with
> the naming of the struct and its members (and maybe it should be in a
>
On Tue, Dec 06, 2022 at 04:57:37PM +0300, Pavel Luzanov wrote:
> On 06.12.2022 03:04, Nathan Bossart wrote:
>> I wonder why \dpS wasn't added. I wrote up a patch to add it and the
>> corresponding documentation that other meta-commands already have.
>
> Yes, \dpS command and clarification in the
On 06.12.2022 03:04, Nathan Bossart wrote:
I wonder why \dpS wasn't added. I wrote up a patch to add it and the
corresponding documentation that other meta-commands already have.
Yes, \dpS command and clarification in the documentation is exactly what
is needed.
--
Pavel Luzanov
Postgres
Nathan Bossart writes:
> diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
> index 3b5ea3c137..bd967eaa78 100644
> --- a/src/backend/catalog/aclchk.c
> +++ b/src/backend/catalog/aclchk.c
> @@ -4202,6 +4202,26 @@ pg_class_aclmask_ext(Oid table_oid, Oid roleid,
> AclMode
On Mon, Dec 05, 2022 at 11:21:08PM +0300, Pavel Luzanov wrote:
> But perhaps this behavior should be reviewed or at least documented?
I wonder why \dpS wasn't added. I wrote up a patch to add it and the
corresponding documentation that other meta-commands already have.
--
Nathan Bossart
Amazon
Hello,
While looking into the new feature, I found the following situation with
the \dp command displaying privileges on the system tables:
GRANT VACUUM, ANALYZE ON TABLE pg_type TO alice;
SELECT relacl FROM pg_class WHERE oid = 'pg_type'::regclass;
relacl
On Mon, Nov 28, 2022 at 12:13:13PM -0500, Andrew Dunstan wrote:
> pushed.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 2022-11-23 We 18:54, Nathan Bossart wrote:
> On Wed, Nov 23, 2022 at 02:56:28PM -0500, Andrew Dunstan wrote:
>> I have committed the first couple of these to get them out of the way.
> Thanks!
>
>> But I think we need a bit of cleanup in the next patch.
>> vacuum_is_relation_owner() looks
On Wed, Nov 23, 2022 at 02:56:28PM -0500, Andrew Dunstan wrote:
> I have committed the first couple of these to get them out of the way.
Thanks!
> But I think we need a bit of cleanup in the next patch.
> vacuum_is_relation_owner() looks like it's now rather misnamed. Maybe
>
On 2022-11-20 Su 11:57, Nathan Bossart wrote:
> On Sat, Nov 19, 2022 at 10:50:04AM -0800, Nathan Bossart wrote:
>> another rebase
> Another rebase for cfbot.
>
I have committed the first couple of these to get them out of the way.
But I think we need a bit of cleanup in the next patch.
On Sat, Nov 19, 2022 at 10:50:04AM -0800, Nathan Bossart wrote:
> another rebase
Another rebase for cfbot.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 5f716f33e93187491686381b2180894ab2b1b92c Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 7 Sep 2022 22:25:29
On Fri, Nov 18, 2022 at 09:05:04AM -0800, Nathan Bossart wrote:
> rebased
another rebase
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 6e2001411107790991037e91f8d2f9411e2f4fa6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 7 Sep 2022 22:25:29 -0700
Subject:
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 0643a4dbc9f36d9fd383ef0cfebef13875237718 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 7 Sep 2022 22:25:29 -0700
Subject: [PATCH v10 1/4] Change AclMode from a uint32 to a uint64.
---
On Wed, Nov 16, 2022 at 03:09:47PM -0500, Andrew Dunstan wrote:
> OK, reading the history I think everyone is on board with expanding
> AclMode from uint32 to uint64. Is that right?
I skimmed through this thread again, and AFAICT folks are okay with this
approach. I'm not aware of any remaining
On 2022-11-15 Tu 00:08, Nathan Bossart wrote:
> On Mon, Nov 14, 2022 at 03:40:04PM -0800, Nathan Bossart wrote:
>> Thanks for taking a look! Here is a rebased version of the patch set.
> Oops, apparently object_aclcheck() cannot be used for pg_class. Here is
> another version that uses
On Mon, Nov 14, 2022 at 03:40:04PM -0800, Nathan Bossart wrote:
> Thanks for taking a look! Here is a rebased version of the patch set.
Oops, apparently object_aclcheck() cannot be used for pg_class. Here is
another version that uses pg_class_aclcheck() instead. I'm not sure how I
missed this
On Fri, Oct 14, 2022 at 07:37:38PM -0400, Corey Huinker wrote:
> Patch applies.
> Passes make check and make check-world.
> Test coverage seems adequate.
>
> Coding is very clear and very much in the style of the existing code. Any
> quibbles I have with the coding style are ones I have with the
>
> Sounds good. Here's a new patch set with aclitem's typalign fixed.
>
Patch applies.
Passes make check and make check-world.
Test coverage seems adequate.
Coding is very clear and very much in the style of the existing code. Any
quibbles I have with the coding style are ones I have with the
On Fri, Sep 30, 2022 at 07:05:38PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote:
>>> ... and now requires double alignment ... did you fix its typalign?
>
>> Nope, I missed that, thanks for pointing it out. Should we move ai_privs
Nathan Bossart writes:
> On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote:
>> ... and now requires double alignment ... did you fix its typalign?
> Nope, I missed that, thanks for pointing it out. Should we move ai_privs
> to the beginning of the struct, too?
Don't see any point, there
On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> The main one I see is AclItem, which increases from 12 bytes to 16 bytes.
>
> ... and now requires double alignment ... did you fix its typalign?
Nope, I missed that, thanks for pointing it out. Should we
Nathan Bossart writes:
> The main one I see is AclItem, which increases from 12 bytes to 16 bytes.
... and now requires double alignment ... did you fix its typalign?
We could conceivably dodge the alignment increase by splitting the 64-bit
field into two 32-bit fields, one for base privileges
On Fri, Sep 30, 2022 at 04:15:24PM -0400, Tom Lane wrote:
> 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
Nathan Bossart 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
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
On Wed, Sep 28, 2022 at 03:09:46PM -0400, Stephen Frost wrote:
> On Wed, Sep 28, 2022 at 14:50 Nathan Bossart
> wrote:
>> I've been testing aclmask() with long aclitem arrays (2,000 entries is
>> close to the limit for pg_class entries), and I haven't found any
>> significant impact from bumping
Greetings,
On Wed, Sep 28, 2022 at 14:50 Nathan Bossart
wrote:
> On Tue, Sep 20, 2022 at 09:31:26PM -0700, Nathan Bossart wrote:
> > I bet a more pressing concern is the calls to aclmask() since checking
> > privileges is probably done more frequently than updating them. That
> > appears to
On Tue, Sep 20, 2022 at 09:31:26PM -0700, Nathan Bossart wrote:
> I bet a more pressing concern is the calls to aclmask() since checking
> privileges is probably done more frequently than updating them. That
> appears to use a linear search, too, so maybe sorting the aclitem arrays is
> actually
On Wed, Sep 21, 2022 at 10:31:47AM +0900, Michael Paquier wrote:
> Did you just run an aclupdate()? 4% for aclitem[] sounds like quite a
> number to me :/ It may be worth looking at if these operations could
> be locally optimized more, as well. I'd like to think that we could
> live with that
On Tue, Sep 20, 2022 at 04:50:10PM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 04:31:17PM -0700, Nathan Bossart wrote:
>> On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
>>> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
Any impact for the column
On Tue, Sep 20, 2022 at 04:31:17PM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
>> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
>>> Any impact for the column sizes of the catalogs holding ACL
>>> information? Just asking while
On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
>> Any impact for the column sizes of the catalogs holding ACL
>> information? Just asking while browsing the patch set.
>
> Since each aclitem requires 16 bytes
On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
> I have gone through the thread, and I'd agree with getting more
> granularity when it comes to assigning ACLs to relations rather than
> just an on/off switch for the objects of a given type would be nice.
> I've been looking at
On Mon, Sep 19, 2022 at 08:51:47PM -0700, Nathan Bossart wrote:
> Are there any concerns with simply expanding AclMode to 64 bits, as done in
> v5 [0]?
>
> [0] https://postgr.es/m/20220908055035.GA2100193%40nathanxps13
I have gone through the thread, and I'd agree with getting more
granularity
On Thu, Sep 08, 2022 at 09:41:20AM -0400, Robert Haas wrote:
> Now on the other hand, I also do think we need more privilege bits.
> You're not alone in making the case that this is a problem which needs
> to be solved, and the set of other people who are also making that
> argument includes me.
On Wed, Sep 07, 2022 at 04:15:23PM -0700, Mark Dilger wrote:
> Ok, now I'm a bit lost. If I want to use Nathan's feature to create a role
> to vacuum and analyze my database on a regular basis, how does per-relation
> granularity help me? If somebody creates a new table and doesn't grant those
On Wed, Sep 7, 2022 at 7:09 PM Stephen Frost wrote:
> Calling this a redesign is over-stating things, imv … and I’d much rather
> have the per-relation granularity than predefined roles for this, so there is
> that to consider too, perhaps.
I also prefer the finer granularity.
On the question
On Wed, Sep 07, 2022 at 07:09:05PM -0400, Stephen Frost wrote:
> Yes, that seems to be the consensus among those involved in this thread
> thus far. Basically, I imagine this involves passing around the object
> type along with the acl info and then using that to check the bits and
> such. I
> On Sep 7, 2022, at 4:09 PM, Stephen Frost wrote:
>
> Calling this a redesign is over-stating things, imv … and I’d much rather
> have the per-relation granularity than predefined roles for this, so there is
> that to consider too, perhaps.
Ok, now I'm a bit lost. If I want to use
Greetings,
On Wed, Sep 7, 2022 at 18:11 Nathan Bossart
wrote:
> On Wed, Sep 07, 2022 at 05:13:44PM -0400, Stephen Frost wrote:
> > I disagree that we should put the onus for addressing this on the next
> > person who wants to add bits and just willfully use up the last of them
> > right now for
> On Sep 7, 2022, at 3:21 PM, Nathan Bossart wrote:
>
> There was some previous discussion around adding a pg_maintenance role that
> could perform all of these commands [0]. I didn't intend to draw a line
> around VACUUM and ANALYZE. Those are just the commands I started with.
> If/when
On Wed, Sep 07, 2022 at 02:53:57PM -0700, Mark Dilger wrote:
> Assuming for the sake of argument that we should create a role something like
> you propose, can you explain why we should draw the line around just VACUUM
> and ANALYZE? I am not arguing for including these other commands, but
On Wed, Sep 07, 2022 at 05:13:44PM -0400, Stephen Frost wrote:
> I disagree that we should put the onus for addressing this on the next
> person who wants to add bits and just willfully use up the last of them
> right now for what strikes me, at least, as a relatively marginal use
> case. If we
> On Jul 22, 2022, at 1:37 PM, Nathan Bossart wrote:
>
> The primary motivation for this is to continue chipping away at things that
> require special privileges or even superuser. VACUUM and ANALYZE typically
> require table ownership, database ownership, or superuser. And only
>
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Tue, Sep 06, 2022 at 11:24:18AM -0400, Robert Haas wrote:
> > On Tue, Sep 6, 2022 at 11:11 AM Stephen Frost wrote:
> >> If we were to make the specific bits depend on the object type as I'm
> >> suggesting, then we'd have 8 bits
On Mon, Sep 05, 2022 at 11:56:30AM -0700, Nathan Bossart wrote:
> Here is a first attempt at allowing users to grant VACUUM or ANALYZE
> per-relation. Overall, this seems pretty straightforward. I needed to
> adjust the permissions logic for VACUUM/ANALYZE a bit, which causes some
> extra
On Tue, Sep 06, 2022 at 11:24:18AM -0400, Robert Haas wrote:
> On Tue, Sep 6, 2022 at 11:11 AM Stephen Frost wrote:
>> If we were to make the specific bits depend on the object type as I'm
>> suggesting, then we'd have 8 bits used for relations (10 with the vacuum
>> and analyze bits), leaving us
On Tue, Sep 6, 2022 at 11:11 AM Stephen Frost wrote:
> Considering our burn rate of ACL bits is really rather slow (2 this
> year, but prior to that was TRUNCATE in 2008 and CONNECT in 2006), I'd
> argue that moving away from the current one-size-fits-all situation
> would kick the can down the
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Tue, Aug 23, 2022 at 07:46:47PM -0400, Stephen Frost wrote:
> > I've long felt that we should redefine the way the ACLs work to have a
> > distinct set of bits for each object type. We don't need to support a
> > CONNECT bit on a
On Mon, Sep 5, 2022 at 2:56 PM Nathan Bossart wrote:
> There are 2 bits remaining at the moment, so I didn't redesign the ACL
> system in the attached patch. However, I did some research on a couple
> options. Using a distinct set of bits for each catalog table should free
> up a handful of
Here is a first attempt at allowing users to grant VACUUM or ANALYZE
per-relation. Overall, this seems pretty straightforward. I needed to
adjust the permissions logic for VACUUM/ANALYZE a bit, which causes some
extra WARNING messages for VACUUM (ANALYZE) in some cases, but this didn't
seem
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jul 26, 2022 at 1:50 PM David G. Johnston
> wrote:
> >> Still, it seems somewhat appealing to give
> >> people fine-grained control over this, rather than just "on" or "off".
> > Appealing enough to consume a couple of permission
On Tue, Jul 26, 2022 at 01:54:38PM -0400, Robert Haas wrote:
> I think we're down to 0 remaining now, so it'd be hard to justify
> consuming 2 of 0 remaining bits.
AFAICT there are 2 remaining. N_ACL_RIGHTS is only 14.
> However, I maintain that the solution
> to this is either (1) change the
At Tue, 26 Jul 2022 13:54:38 -0400, Robert Haas wrote
in
> On Tue, Jul 26, 2022 at 1:50 PM David G. Johnston
> wrote:
> >> Still, it seems somewhat appealing to give
> >> people fine-grained control over this, rather than just "on" or "off".
> > Appealing enough to consume a couple of
On Tue, Jul 26, 2022 at 1:50 PM David G. Johnston
wrote:
>> Still, it seems somewhat appealing to give
>> people fine-grained control over this, rather than just "on" or "off".
> Appealing enough to consume a couple of permission bits?
>
On Tue, Jul 26, 2022 at 10:37 AM Robert Haas wrote:
> On Mon, Jul 25, 2022 at 9:47 PM Kyotaro Horiguchi
> wrote:
> > One arguable point would be whether we will need to put restriction
> > the target relations that Bob can vacuum/analyze.
>
> But for a command with a target, you really ought
On Mon, Jul 25, 2022 at 9:47 PM Kyotaro Horiguchi
wrote:
> One arguable point would be whether we will need to put restriction
> the target relations that Bob can vacuum/analyze.
Yeah. pg_checkpoint makes sense because you can either CHECKPOINT or
you can't. But for a command with a target, you
At Tue, 26 Jul 2022 10:47:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> WARNING: skipping "pg_statistic" --- only superusers, roles with privileges
> of pg_vacuum_analyze, or the database owner can vacuum it
> WARNING: skipping "pg_type" --- only superusers, roles with privileges of
>
At Mon, 25 Jul 2022 09:40:49 -0700, Nathan Bossart
wrote in
> On Mon, Jul 25, 2022 at 12:58:36PM +0530, Bharath Rupireddy wrote:
> > Thanks. I'm personally happy with more granular levels of control (as
> > we don't have to give full superuser access to just run a few commands
> > or
On Mon, Jul 25, 2022 at 12:58:36PM +0530, Bharath Rupireddy wrote:
> Thanks. I'm personally happy with more granular levels of control (as
> we don't have to give full superuser access to just run a few commands
> or maintenance operations) for various postgres commands. The only
> concern is that
On Sat, Jul 23, 2022 at 2:07 AM Nathan Bossart wrote:
>
> Hi hackers,
>
> The previous attempt to add a predefined role for VACUUM and ANALYZE [0]
> resulted in the new pg_checkpoint role in v15. I'd like to try again to
> add a new role (or multiple new roles) for VACUUM and ANALYZE.
>
> The
On Fri, Jul 22, 2022 at 01:37:35PM -0700, Nathan Bossart wrote:
> The attached patch adds a pg_vacuum_analyze role that allows VACUUM and
> ANALYZE commands on all relations. I started by trying to introduce
> separate pg_vacuum and pg_analyze roles, but that quickly became
> complicated because
Hi hackers,
The previous attempt to add a predefined role for VACUUM and ANALYZE [0]
resulted in the new pg_checkpoint role in v15. I'd like to try again to
add a new role (or multiple new roles) for VACUUM and ANALYZE.
The primary motivation for this is to continue chipping away at things that
63 matches
Mail list logo
