Re: SET variable - Permission issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SET variable - Permission issues
Date
Msg-id 11314.1318091408@sss.pgh.pa.us
Whole thread Raw
In response to SET variable - Permission issues  (Josh <josh@schemaverse.com>)
Responses Re: SET variable - Permission issues
List pgsql-hackers
Josh <josh@schemaverse.com> writes:
> [ unhappy about users being able to freely adjust work_mem etc ]

Really, if you're letting users issue arbitrary SQL queries, there
simply isn't any way to prevent them from beating your server into
the ground.  I don't think that inserting a hack to prevent specific
configuration variables from being adjusted is going to help you
against an uncooperative user.  You'd be better off to rethink the
"let them issue SQL queries directly" part of your design.

The reason that the specific variables you mention (as well as some
others that bear on such things) are USERSET and not SUSET is precisely
that we are not trying to constrain the amount of resources an
uncooperative user can consume.  If we did try to do that, quite a
lot of design decisions would have to be revisited, and there would
be a number of unpleasant tradeoffs to be made.  GUC privilege levels
are just the tip of the iceberg.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Next
From: "Kevin Grittner"
Date:
Subject: REVIEW: Optimizing box_penalty