Re: Index build temp files
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers@postgresql.org
Date: 2013-01-09T21:21:18Z
Lists: pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.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