> On Mar 28, 2017, at 8:34 AM, Dave Page <dpage@pgadmin.org> wrote:
>
> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> 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 in a new version.
>
> Right now I'm waiting for discussion to conclude before updating the
> patch again.
There does not seem to be a new patch since Robert made his "modest proposal",
so I guess I just have to ask questions about how this would work.
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.
If I have even one table in my database which is security sensitive, such that
I cannot allow users to see the size of the table, nor whether the table has
unvacuumed rows (owing to the fact that would give away that it has been
changed since the last vacuum time), then I can't use pg_real_all_stats for
anything, right? And I would need to exercise some due diligence to make
certain it does not get granted to anybody?
What happens if I execute:
REVOKE ALL ON TABLE mysecuretable FROM pg_read_all_stats?
Does it work? Does it silently fail? Does it raise an exception? Does
pg_read_all_stats still have access to stats for mysecuretable?
mark