Still a loose end in GUC USERLIMIT stuff
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 depend on 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
Tom Lane wrote:
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 depend on 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;
#endifIt'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.
This is tough, but looking at CVS it doesn't appear as you showed above.
Is there a later email that hasn't arrived yet?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073