On Thu, Mar 30, 2017 at 2:24 PM, Simon Riggs wrote:
> On 30 March 2017 at 18:29, Simon Riggs wrote:
>
>> Moving to commit this over the next hour. Last chance...
>
> Done. Great work Dave, thanks everybody.
Thanks Simon.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
Enterpr
On 30 March 2017 at 18:29, Simon Riggs wrote:
> Moving to commit this over the next hour. Last chance...
Done. Great work Dave, thanks everybody.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql
On 29 March 2017 at 21:42, Dave Page wrote:
> On Wed, Mar 29, 2017 at 2:51 PM, Stephen Frost wrote:
>>
>> Dave's currently hacking on a new patch based on our discussion, so I'd
>> suggest waiting another hour or so anyway until he's done.
>>
>> Might be a bit longer as he's trying to do it in a
On Wed, Mar 29, 2017 at 2:51 PM, Stephen Frost wrote:
>
> Dave's currently hacking on a new patch based on our discussion, so I'd
> suggest waiting another hour or so anyway until he's done.
>
> Might be a bit longer as he's trying to do it in a hallway at
> PGConf.US...
Thanks Stephen.
Here's a
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/28/17 12:19, Dave Page wrote:
> > On Tue, Mar 28, 2017 at 11:39 AM, Peter Eisentraut
> > wrote:
> >> On 3/28/17 11:34, Dave Page wrote:
> >>> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
> >>> wrote:
> This patch touch
On 3/28/17 12:19, Dave Page wrote:
> On Tue, Mar 28, 2017 at 11:39 AM, Peter Eisentraut
> wrote:
>> On 3/28/17 11:34, Dave Page wrote:
>>> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
>>> wrote:
This patch touches the pg_buffercache and pg_freespacemap extensions,
but there appear
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> OK, so essentially what I did, except s/pg_read_all_stats/pg_read_all_queries
> ?
Yup.
> So pgstattuple, pg_sfreespacemap, pg_visibility and pgrowlocks to be
> allowed access from members of pg_stat_scan_tables, which in turn is
> granted to pg_mon
> On Mar 28, 2017, at 1:17 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I don't see anything wrong with adding roles in pg_authid.h with a #define'd
>> Oid. That's actually pretty helpful for anyone writing code against the
>> database,
>> as they don't have to look up the Oid of the role.
Mark Dilger writes:
> I don't see anything wrong with adding roles in pg_authid.h with a #define'd
> Oid. That's actually pretty helpful for anyone writing code against the
> database,
> as they don't have to look up the Oid of the role.
> But why not then grant privileges to that role in infor
Hi
On Tue, Mar 28, 2017 at 2:22 PM, Stephen Frost wrote:
> Dave,
>
> * Dave Page (dp...@pgadmin.org) wrote:
>> OK, so before I start hacking again, here's a proposal based on my
>> understanding of folks comments, and so open questions. If I can get
>> agreement and answers, I'll be able to break
> On Mar 28, 2017, at 11:52 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> After a bit of introspection, I think what is really bothering me is not the
>> inability to revoke permissions, since as you say I can choose to not assign
>> the role to anybody. What bothers me is that this feature i
Mark Dilger writes:
> After a bit of introspection, I think what is really bothering me is not the
> inability to revoke permissions, since as you say I can choose to not assign
> the role to anybody. What bothers me is that this feature implicitly
> redefines
> what is meant by the keyword PUBL
Greetings,
* Mark Dilger (hornschnor...@gmail.com) wrote:
> After a bit of introspection, I think what is really bothering me is not the
> inability to revoke permissions, since as you say I can choose to not assign
> the role to anybody. What bothers me is that this feature implicitly
> redefin
> On Mar 28, 2017, at 11:06 AM, Mark Dilger wrote:
>
>
>> On Mar 28, 2017, at 9:47 AM, Dave Page wrote:
>>
>>> Does
>>> pg_read_all_stats still have access to stats for mysecuretable?
>>
>> Yes, because the ACL on the table controls reading/writing the data in
>> the table. It doesn't have a
Greetings,
* Mark Dilger (hornschnor...@gmail.com) wrote:
> The inability to revoke access to this sort of information being proposed
> makes me a bit uneasy.
What data are you concerned about, specifically?
> Mostly, I think, I'm bothered because there may
> be people who have revoked privile
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> OK, so before I start hacking again, here's a proposal based on my
> understanding of folks comments, and so open questions. If I can get
> agreement and answers, I'll be able to break out vi again without
> (hopefully) too many more revisions:
>
> p
> On Mar 28, 2017, at 9:47 AM, Dave Page wrote:
>
>> Does
>> pg_read_all_stats still have access to stats for mysecuretable?
>
> Yes, because the ACL on the table controls reading/writing the data in
> the table. It doesn't have any bearing on any kind of table metadata.
> A user who has no pri
On Tue, Mar 28, 2017 at 1:52 PM, Mark Dilger wrote:
>
>> On Mar 28, 2017, at 9:55 AM, Robert Haas wrote:
>>
>> On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote:
I don't see any precedent in the code for having a hardcoded role, other
than
superuser, and allowing privileges based
> On Mar 28, 2017, at 9:55 AM, Robert Haas wrote:
>
> On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote:
>>> I don't see any precedent in the code for having a hardcoded role, other
>>> than
>>> superuser, and allowing privileges based on a hardcoded test for membership
>>> in that role. I'm
OK, so before I start hacking again, here's a proposal based on my
understanding of folks comments, and so open questions. If I can get
agreement and answers, I'll be able to break out vi again without
(hopefully) too many more revisions:
pg_read_all_stats: Will have C-coded access to pg_stats vie
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote:
> >> I don't see any precedent in the code for having a hardcoded role, other
> >> than
> >> superuser, and allowing privileges based on a hardcoded test for membership
> >> in that role.
On Tue, Mar 28, 2017 at 12:55 PM, Robert Haas wrote:
> On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote:
>>> I don't see any precedent in the code for having a hardcoded role, other
>>> than
>>> superuser, and allowing privileges based on a hardcoded test for membership
>>> in that role. I'm s
On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote:
>> I don't see any precedent in the code for having a hardcoded role, other than
>> superuser, and allowing privileges based on a hardcoded test for membership
>> in that role. I'm struggling to think of all the security implications of
>> that.
On Tue, Mar 28, 2017 at 12:04 PM, Mark Dilger wrote:
>
>> On Mar 28, 2017, at 8:34 AM, Dave Page wrote:
>>
>> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
>> wrote:
>>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>>> but there appear to be some files missing.
>>
>
On Tue, Mar 28, 2017 at 11:39 AM, Peter Eisentraut
wrote:
> On 3/28/17 11:34, Dave Page wrote:
>> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
>> wrote:
>>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>>> but there appear to be some files missing.
>>
>> Are you loo
> On Mar 28, 2017, at 8:34 AM, Dave Page wrote:
>
> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
> wrote:
>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>> but there appear to be some files missing.
>
> Are you looking at an old version? There was one where I fo
On 3/28/17 11:34, Dave Page wrote:
> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
> wrote:
>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>> but there appear to be some files missing.
>
> Are you looking at an old version? There was one where I forgot to add
> some
On 3/27/17 08:54, Robert Haas wrote:
> OK, I see the points that both of you are making and I admit that
> they've got some validity to them. Let me make a modest proposal.
> Suppose we define the pg_monitor role as strictly a bundle of
> privileges that could be granted individually if desired, a
On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
wrote:
> This patch touches the pg_buffercache and pg_freespacemap extensions,
> but there appear to be some files missing.
Are you looking at an old version? There was one where I forgot to add
some files, but that was fixed within an hour or so
This patch touches the pg_buffercache and pg_freespacemap extensions,
but there appear to be some files missing.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 3/28/17 10:24, Simon Riggs wrote:
>> Let me make a modest proposal.
>
> +1
>
> I aim to commit something today. If you have other viewpoints, so say
> now. There aren't many days left to express views and do anything
> about them, so lets do it.
I don't even see an actual proposed patch here,
On 27 March 2017 at 13:54, Robert Haas wrote:
> On Sat, Mar 25, 2017 at 12:30 PM, Dave Page wrote:
>> Right - and if a user doesn't like it, they can easily just not use the
>> default role and create their own alternative instead.
>
> OK, I see the points that both of you are making and I admit
On 23 March 2017 at 13:16, Dave Page wrote:
> Thanks - updated patch attached.
I've edited the comments and docs on this patch, so attach a new
version with similar name.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Serv
On Sat, Mar 25, 2017 at 12:30 PM, Dave Page wrote:
> Right - and if a user doesn't like it, they can easily just not use the
> default role and create their own alternative instead.
OK, I see the points that both of you are making and I admit that
they've got some validity to them. Let me make
On Mon, Mar 27, 2017 at 3:51 AM, Simon Riggs wrote:
> On 25 March 2017 at 16:30, Dave Page wrote:
>
>> I believe this and other reasons we've described are exactly why other DBMS'
>> do what we're proposing.
>
> It would help review if you could show some links and give a
> commentary on what yo
On 23 March 2017 at 13:16, Dave Page wrote:
> Thanks - updated patch attached.
No problems with the patch so far.
I'd like some tests though...
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-
On 25 March 2017 at 16:30, Dave Page wrote:
> I believe this and other reasons we've described are exactly why other DBMS'
> do what we're proposing.
It would help review if you could show some links and give a
commentary on what you think others do, what they get right and what
they get wrong,
Hi
> On 25 Mar 2017, at 15:55, Stephen Frost wrote:
>
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>>> On Fri, Mar 24, 2017 at 12:46 PM, Dave Page wrote:
On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas wrote:
That's possible, but it really depends on the tool, not on core
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 24, 2017 at 8:30 AM, Stephen Frost wrote:
> >> But why not do it with GRANTs in the first place then?
> >
> > This is akin to asking why do we need GRANT ALL and ALTER DEFAULT PRIVs.
I wasn't very clear with my thinking as to why
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 24, 2017 at 12:46 PM, Dave Page wrote:
> > On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas wrote:
> >> That's possible, but it really depends on the tool, not on core
> >> PostgreSQL. The tool should be the one providing the script
On Fri, Mar 24, 2017 at 12:46 PM, Dave Page wrote:
> On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas wrote:
>>> If we make the users run all the statements individually then they'll
>>> also have to get an updated script for the next version of PG too
>>> because we will have added things that the t
On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas wrote:
>
>> If we make the users run all the statements individually then they'll
>> also have to get an updated script for the next version of PG too
>> because we will have added things that the tools will want access to.
>
> That's possible, but it r
On Fri, Mar 24, 2017 at 8:30 AM, Stephen Frost wrote:
>> But why not do it with GRANTs in the first place then?
>
> This is akin to asking why do we need GRANT ALL and ALTER DEFAULT PRIVs.
Not really. ALTER DEFAULT PRIVILEGES affects what happens for future
objects, which isn't necessary here at
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/22/17 09:17, Stephen Frost wrote:
> >> If we do it via GRANTs instead, then users can easily extend it.
> > The intent here is that users will *also* be able to do it via GRANTs if
> > they wish to.
>
> But why not do it w
On 3/22/17 09:17, Stephen Frost wrote:
>> If we do it via GRANTs instead, then users can easily extend it.
> The intent here is that users will *also* be able to do it via GRANTs if
> they wish to.
But why not do it with GRANTs in the first place then?
--
Peter Eisentraut http://www
Hi
On Thu, Mar 23, 2017 at 12:23 PM, Stephen Frost wrote:
>
>> diff --git a/contrib/pg_stat_statements/pg_stat_statements.c
>> b/contrib/pg_stat_statements/pg_stat_statements.c
>> index 221ac98d4a..cec94d5896 100644
>> --- a/contrib/pg_stat_statements/pg_stat_statements.c
>> +++ b/contrib/pg_sta
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Wed, Mar 22, 2017 at 3:46 PM, Dave Page wrote:
> > On Wed, Mar 22, 2017 at 1:15 PM, Stephen Frost wrote:
> >> I did specifically ask for explicit roles to be made to enable such
> >> capability and that the pg_monitor role be GRANT'd those roles
On Wed, Mar 22, 2017 at 3:46 PM, Dave Page wrote:
> On Wed, Mar 22, 2017 at 1:15 PM, Stephen Frost wrote:
>>
>> I did specifically ask for explicit roles to be made to enable such
>> capability and that the pg_monitor role be GRANT'd those roles instead
>> of hacking the pg_monitor OID into those
On Wed, Mar 22, 2017 at 1:15 PM, Stephen Frost wrote:
>
> I did specifically ask for explicit roles to be made to enable such
> capability and that the pg_monitor role be GRANT'd those roles instead
> of hacking the pg_monitor OID into those checks, but it seems like
> that's not been done yet.
Y
On Wed, Mar 22, 2017 at 12:55 PM, Peter Eisentraut
wrote:
> On 3/22/17 07:48, Dave Page wrote:
>> With the patch, complex monitoring systems can easily be setup with
>> something like:
>>
>> CREATE ROLE monitoring_user LOGIN;
>> GRANT pg_monitor TO monitoring_role;
>
> That assumes that we have th
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/22/17 07:48, Dave Page wrote:
> > With the patch, complex monitoring systems can easily be setup with
> > something like:
> >
> > CREATE ROLE monitoring_user LOGIN;
> > GRANT pg_monitor TO monitoring_role;
>
> That assume
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 22, 2017 at 7:48 AM, Dave Page wrote:
> >> I'd be inclined to skip the rest of
> >> this. If an individual user wants to grant that bundle of privileges
> >> to a role, they can do it with or without pg_monitor.
> >
> > GRANT cannot be us
On 3/22/17 07:48, Dave Page wrote:
> With the patch, complex monitoring systems can easily be setup with
> something like:
>
> CREATE ROLE monitoring_user LOGIN;
> GRANT pg_monitor TO monitoring_role;
That assumes that we have thought of all the ways in which people might
want to monitor things.
On Wed, Mar 22, 2017 at 7:48 AM, Dave Page wrote:
>> I'd be inclined to skip the rest of
>> this. If an individual user wants to grant that bundle of privileges
>> to a role, they can do it with or without pg_monitor.
>
> GRANT cannot be used in all cases, as some of the functions changed
> have
On Wed, Mar 22, 2017 at 11:32 AM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 5:14 AM, Dave Page wrote:
>> - Adds a default role called pg_monitor
>> - Gives members of the pg_monitor role full access to:
>> pg_ls_logdir() and pg_ls_waldir()
>> pg_stat_* views and functions
>> pg_tab
On Fri, Feb 24, 2017 at 5:14 AM, Dave Page wrote:
> - Adds a default role called pg_monitor
> - Gives members of the pg_monitor role full access to:
> pg_ls_logdir() and pg_ls_waldir()
> pg_stat_* views and functions
> pg_tablespace_size() and pg_database_size()
> Contrib modules:
On 2/24/17 05:14, Dave Page wrote:
> - Adds a default role called pg_read_all_gucs
> - Allows members of pg_read_all_gucs to, well, read all GUCs
> - Grants pg_read_all_gucs to pg_monitor
Maybe pg_read_all_settings? Consistent with pg_settings.
--
Peter Eisentraut http://www.2ndQua
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good.
--
Sent via pgsql-hackers mailing list (pgsql-ha
Hi
On Thu, Mar 16, 2017 at 7:04 PM, Denish Patel wrote:
> Hi Dave,
>
> The patch failed applied...
>
> patch -p1 < /home/vagrant/pg_monitor.diff
> patching file contrib/pg_buffercache/Makefile
> patching file contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql
> patching file contrib/pg_buffercac
Hi Dave,
The patch failed applied...
patch -p1 < /home/vagrant/pg_monitor.diff
patching file contrib/pg_buffercache/Makefile
patching file contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql
patching file contrib/pg_buffercache/pg_buffercache.control
patching file contrib/pg_freespacemap/Makefile
Per the discussion at
https://www.postgresql.org/message-id/CA%2BOCxoyYxO%2BJmzv2Micj4uAaQdAi6nq0w25BPQgLLxsrvTmREw%40mail.gmail.com,
attached is a patch that implements the following:
- Adds a default role called pg_monitor
- Gives members of the pg_monitor role full access to:
pg_ls_logdir()
61 matches
Mail list logo
