Still a loose end in GUC USERLIMIT stuff
От | Tom Lane |
---|---|
Тема | Still a loose end in GUC USERLIMIT stuff |
Дата | |
Msg-id | 14345.1093981361@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Still a loose end in GUC USERLIMIT stuff
|
Список | pgsql-hackers |
As of CVS tip, an increase in a USERLIMIT parameter in postgresql.conf will be enforced against the sessions of superusers as well as everyone else. That's because I ifdef'd out this code: /* * If user is a superuser, he gets to keep his setting. We can't check * this unless inside a transaction, though. XXX in practice that * restriction means this code is essentially worthless, because the * result will dependon whether we happen to be inside a transaction * block when SIGHUP arrives. Dike out until we can think of something * that actually works. */ #ifdef NOT_USED if (IsTransactionState() && superuser()) return false; #endif It'd be better if it worked as originally intended, but this code cannot be made to do that with any reliability. The superuser() test has another problem besides what I mentioned in the comment, which is that its result will vary depending on SET SESSION AUTHORIZATION, SECURITY INVOKER function calls, and so on; so it might return an indication that has nothing to do with the privileges that were used when the GUC variable was set. Offhand the only reasonable way I can see to handle this is that *when a setting is made* we set a flag bit on the GUC variable showing whether it was set by a superuser or not, and then check that flag rather than the current superuser state when deciding whether to override the value. I am not sure it's really worth the trouble though. Also this would not be exactly the original coding intention, I think, because the original code attempted to protect the superuser's effective setting whether he had explicitly set the value or just inherited it from postgresql.conf. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: