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

Re: Index build temp files

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Index build temp files
Date: 2013-01-09 21:21:18
Message-ID: 20130109212118.GR16126@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> IIRC, we do have mechanism now whereby a superuser can establish settings
> for SUSET variables via ALTER ROLE SET/ALTER DATABASE SET, and
> everything works as expected.

I'm not entirely convinced that it works as expected, at least for
temp_tablespaces currently.  This was a bit surprising to me:

=# alter user test_role set temp_tablespaces='zz';
NOTICE:  tablespace "zz" does not exist
ALTER ROLE
=*# commit;
COMMIT
=# set role test_role;
SET
=*> show temp_tablespaces;
 temp_tablespaces 
------------------
 rn_temp_01
(1 row)

> So the only loss of flexibility here
> would be if you want unprivileged code to be able to set
> temp_tablespaces for itself.

I'm on the fence about this one.  I could see that being useful in some
cases when there are a lot of temporary tables being created and you
need more than one tablespace for simple space reasons.  It'd be
unfortuante if you had to be a superuser and/or call a superuser
security definer function to handle that situation.

> However, if you want that then it's hard
> to argue that there shouldn't be a permissions check, and then we're
> back into the surprises mentioned previously.

I'm not sure we're going to be able to get away from that.

> It might be possible to compromise on an arrangement whereby tablespace
> permissions checking only occurs if the active value of the variable was
> set by a non-superuser.  But TBH that idea fills me with dread --- we
> don't have any other GUCs that work like that, and it seems too likely
> that there would be conceptual or implementation bugs in it.

I don't particularly like that either.

	Thanks,

		Stephen

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2013-01-09 21:27:38
Subject: Re: Index build temp files
Previous:From: Tom LaneDate: 2013-01-09 21:21:03
Subject: Re: Index build temp files

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