Skip site navigation (1) Skip section navigation (2)

Re: Index build temp files

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Index build temp files
Date: 2013-01-09 21:52:31
Message-ID: CA+U5nMK7cJ78ker5niKJx=3B+gLZpvNV0TQvk-YHvYVeKcUmfA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 9 January 2013 21:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 9 January 2013 21:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This sounds like rather a lot of work to create a behavior that doesn't
>>> solve the originally-complained-of usability problem.  All it does is
>>> make things even more complicated, and add an extra step for the DBA
>>> who's just trying to set temp_tablespaces to something useful.
>
>> There is already an extra step to GRANT the CREATE privilege, so how
>> does this change things?
>
> The point is that it didn't occur to Stephen that putting
> temp_tablespaces = 'foo, bar' into postgresql.conf should require
> doing GRANT CREATE TO PUBLIC on those tablespaces in order to be
> effective.  Changing the situation so that instead he needs to do
> GRANT TEMP TO PUBLIC does not make it one whit more usable.
>
> All that that will really accomplish is to break grant methods that are
> working in (other people's) existing installations; ie if someone has
> code that does know about the GRANT CREATE requirement, he will not
> thank us if he suddenly has to spell it GRANT TEMP in the next release.
>
> If we were designing this from scratch I'd agree that a separate TEMP
> privilege would be a good thing.  But bolting one on now is likely
> to create more problems than it fixes.  Particularly since it doesn't
> actually fix any of the concrete problems enumerated in this thread.
>
> I continue to think that getting rid of the privilege check would be
> a more useful answer than changing which privilege is tested.

I wasn't suggesting that we test for TEMP instead of CREATE; what I
meant was we would test for CREATE *OR* TEMP to give more options for
management. Since CREATE is a powerful privilege, secure systems would
not wish to grant that to everyone, which is what I think caused the
issue, coupled with the inability to know whether temp_tablespaces is
set to something you have privileges on.

Your suggestion to make TEMP the default would be a useful way to
handle this, but its still the opposite of how things work now.

Granting CREATE by default on tablespaces is not a great plan.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-09 22:06:49
Subject: Re: Reducing size of WAL record headers
Previous:From: Andrew DunstanDate: 2013-01-09 21:49:30
Subject: Re: PL/perl should fail on configure, not make

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group