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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
