Re: Review of GetUserId() Usage
От | Peter Eisentraut |
---|---|
Тема | Re: Review of GetUserId() Usage |
Дата | |
Msg-id | 54245C53.8070906@gmx.net обсуждение исходный текст |
Ответ на | Re: Review of GetUserId() Usage (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Review of GetUserId() Usage
Re: Review of GetUserId() Usage Re: Review of GetUserId() Usage |
Список | pgsql-hackers |
On 9/24/14 4:58 PM, Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: >> I think the case for pgstat_get_backend_current_activity() and >> pg_stat_get_activity and the other pgstatfuncs.c callers is easy to make >> and seems acceptable to me; but I would leave pg_signal_backend out of >> that discussion, because it has a potentially harmful side effect. By >> requiring SET ROLE you add an extra layer of protection against >> mistakes. (Hopefully, pg_signal_backend() is not a routine thing for >> well-run systems, which means human intervention, and therefore the room >> for error isn't insignificant.) > > While I certainly understand where you're coming from, I don't really > buy into it. Yes, cancelling a query (the only thing normal users can > do anyway- they can't terminate backends) could mean the loss of any > in-progress work, but it's not like 'rm' and I don't see that it needs > to require extra hoops for individuals to go through. It would be weird if it were inconsistent: some things require role membership, some things require SET ROLE. Try explaining that.
В списке pgsql-hackers по дате отправления: