On Mon, Oct 10, 2011 at 1:06 PM, Joe Conway <m...@joeconway.com> wrote:
> 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
