From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Only owners can ANALYZE tables...seems overly restrictive |
Date: | 2016-02-29 14:15:21 |
Message-ID: | CAECtzeWvxo2eGD5k2ZJ43rLXai_eXHzBGJAWq243yeiZqB91Nw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2016-02-29 14:31 GMT+01:00 Stephen Frost <sfrost(at)snowman(dot)net>:
> * David G. Johnston (david(dot)g(dot)johnston(at)gmail(dot)com) wrote:
> > Given the amount of damage a person with write access to a table can get
> > into it seems pointless to not allow them to analyze the table after
> their
> > updates - since best practices would say that normal work with a table
> > should not be performed by an owner.
> >
> > I should the check for whether a given user can or cannot analyze a table
> > should be whether the user has INSERT, UPDATE, or DELETE privileges.
>
> Realistically, ANALYZE is a background/maintenance task that autovacuum
> should be handling for you.
>
>
Realistically, that can't happen every time. Think of temporary tables for
example...
> > I suppose row-level-security might come into play here...
>
> Yes, you may only have access to a subset of the table.
>
> If we had plenty more bits to allow ANALYZE to be independently
> GRANT'able, then maybe, but those are a limited resource.
>
>
Agreed.
--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Winkless | 2016-02-29 14:19:45 | Re: multicolumn index and setting effective_cache_size using human-readable-numbers |
Previous Message | Geoff Winkless | 2016-02-29 14:07:56 | Re: multicolumn index and setting effective_cache_size using human-readable-numbers |