Re: Additional role attributes && superuser review

On Mon, Jan 4, 2016 at 5:22 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> So, is this another case where the support is all in off-list fora and
>> thus invisible, or can you point to specific on-list discussions where
>> it was supported, and to the opinions offered in support? I don't
>> really remember many opinions that were any more positive than "I
>> wouldn't be strongly opposed to this" or "If we're going to do this
>> then we ought to do it in X way". I'm happy to be corrected if I'm
>> misrepresenting the record, but I'd characterize the overall reaction
>> to this proposal as tepid: nobody hated it, but nobody really loved it
>> either, and a bunch of mild concerns were offered.
>
> I agree that this has largely been the on-list reaction. To be fair,
> it's been largely the off-list reaction also, which I've expressly
> tried to seek out, as mentioned above. I'm not asking anyone to love
> it, I'm not entirely convinced it's lovable myself, but I do feel it's
> useful and worth making an effort for.

I think the question of whether the specific proposals on the table
are in fact useful is one that deserves more study. I am not
convinced of that. I believe something like this could be useful, but
I don't see a lot of evidence that the particular roles you're arguing
for actually are.

> I'd love to have folks from other companies involved in these
> discussions. I'll even reach out explicitly to seek their comment, as
> I've done with other hackers at conferences, and try to get them to
> voice their opinions here.

Great, thanks.

>> What really bothers me about this thread is that these predefined
>> roles are intended to be useful for third-party tools, but the people
>> who maintain those third-party tools have said basically nothing.
>
> For my 2c, I believe that to be, by-and-large, because they don't want
> to get their hopes up until they see something actually get committed.
> Following long and deep threads such as these are quite a committment.

Yep.

>> I
>> don't recall, for example, Dave Page weighing in on what pgAdmin
>> needs, or anybody commenting on to what degree any of these proposals
>> would meet the needs of Slony or pgBouncer or pgPool or any backup
>> tool (other than perhaps pgbackrest, which I assume your proposals
>> cater to) or any monitoring tool. Like, we've heard zip. Either
>> those people don't know this thread exists, or they can't understand
>> it, or they think it's so boring that they can't be bothered to write
>> in and say whether this is useful or not. I'd have a lot more
>> confidence that we are making a good decision if some of those people
>> would show up and say "I have reviewed this proposal and it looks {
>> great | terrible | mediocre } for $TOOL because $REASON".
>
> We *have* heard complaints from people, multiple times on various lists,
> that they'd like to set up check_postgres, Nagios, $MONITORINGTOOL, with
> a role that *isn't* a superuser.

True. But we should verify that this proposal actually meets those
needs, not just assume it does.

> I'll ask Greg S-M if he would have
> time to weigh in on this though, check_postgres was specifically one of
> the tools which I was looking at when considering the pg_monitor role.

OK, that sounds like a good idea.

> I'm not sure about the references you use above to Slony or pgBouncer or
> pgPool as those aren't backup tools, to my mind.. I would expect barman
> and other backup tools to also use pg_start/stop_backup and
> pg_switch_xlog. I'm not sure that there's a way to cater to one backup
> role when it comes to how filesystem-level backups are handled in PG,
> but perhaps I've missed something there that barman uses and which isn't
> included currently.

Oh, sure: they are not backup tools specifically. But anything that
might need elevated privileges deserves consideration here: what sort
of subdivision of the superuser role would make that need go away?

> Of course, my reviewing barman or other tools wouldn't have the same
> support as Simon weighing in, so I'll try and pursue that avenue as
> well.

Cool.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company