From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Still a loose end in GUC USERLIMIT stuff |
Date: | 2004-08-31 19:42:41 |
Message-ID: | 14345.1093981361@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Serguei A. Mokhov | 2004-08-31 20:13:38 | Resurrecting pg_upgrade |
Previous Message | Bruce Momjian | 2004-08-31 18:57:28 | Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE |