Re: SET variable - Permission issues

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

In response to

Responses

Browse pgsql-hackers by date

  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)