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

Tue, 31 Aug 2004 15:42:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Still a loose end in GUC USERLIMIT stuff
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;
> #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.

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

Tue, 31 Aug 2004 22:51:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a loose end in GUC USERLIMIT stuff