On 10/09/2011 09:09 PM, Robert Haas wrote: > Having said that, I do think it might be useful to have ways of > controlling the values that users can set for GUC values, not so much > as a guard against an all-out assault (which is probably futile) but > as a way for DBAs to enforce system policy. But even that seems like > a lot of work for a fairly marginal benefit....
I think the issues Josh raised are valid concerns for a number of use cases. Even if you don't want to allow anyone on the Internet into your database (as Josh does, since his application is a game and his attempt is to set policies and privileges such that it is actually safe), there are plenty of companies needing to run Postgres in a multi-tenant environment.
Currently customer A can set work_mem = <some very large number>; and set statement_timeout = 0; and run a big query effectively DOS'ing customers B, C, and D. If these two settings could be restricted by the DBA, there would be a much lower chance of this happening. There are undoubtedly other holes to fill, but it seems like a worthy cause.
Even in a controlled environment, say in a company where only legit apps developed in-house are run on the DB, a DBA would want peace of mind that the developers are not setting these GUCs at runtime (which is often even recommended in case of work_mem) to bypass a policy set by the DBA and are capable of bringing the DB down to its knees.
Regards, --
Gurjeet Singh EnterpriseDB Corporation The Enterprise PostgreSQL Company