From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh <josh(at)schemaverse(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SET variable - Permission issues |
Date: | 2011-10-08 16:30:08 |
Message-ID: | 11314.1318091408@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh <josh(at)schemaverse(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-10-08 18:51:11 | REVIEW: Optimizing box_penalty |
Previous Message | Jeff Davis | 2011-10-08 16:27:53 | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) |