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 20:49:47
Message-ID: 20130109204947.GP16126@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> We do have mechanism that forces search_path to be recomputed across
> changes of active role, but it's expensive to do that, and it seems
> of rather debatable value to do it here --- it certainly wouldn't
> improve Stephen's original problem, much less the other issues he
> raises here.

I agree that we would need something more for users to be able to be
able to tell what temp tablespace their temporary tables will end up in.
Generally, I think it'd be acceptable from a performance perspective to
figure out where to create the temporary objects at the time that they
are requested- at that point, you're going to be creating a new table,
index, or doing a large sort that spills to disk, all of which are
relatively heavy-weight operations.

> What would people think of just eliminating the access-permissions
> checks involved in temp_tablespaces?  It would likely be appropriate to
> change temp_tablespaces from USERSET to SUSET if we did so.  So
> essentially the worldview would become that the DBA is responsible for
> the temp_tablespaces setting, not individual users.

I believe it's important to be able to control what temp tablespaces are
used on a per-user basis and that 'set role;' or security definer
functions respect the tablespace which has been set for the current
role.  Temp tablespaces are extremely valuable for managing users who
unintentionally write run-away queries that fill up the tablespace.
Keeping those seperate from the temp tablespace used for SECURITY
DEFINER functions (which are written with care) or other ongoing system
activity is necessary.  Perhaps there would be a way to still do that
with your approach, but it didn't sound like it initially.

Perhaps we can simply keep track of what the current role was when we
cache'd which temp tablespace was selected for a given session and, if
the current role has changed, reconsider the temp tablespace selected?
We would need to update the documentation to reflect that you might not
*always* have the same tablespace for a session, if there are security
definer and/or set role's happening, but that seems reasonable to me.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2013-01-09 20:53:05
Subject: Re: Index build temp files
Previous:From: Tom LaneDate: 2013-01-09 20:43:19
Subject: Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

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