Re: Index build temp files - Mailing list pgsql-hackers

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.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.

> 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.

It's not so much performance I'm worried about here as
modularity/layering issues.  Actual use of the temp-tablespaces list to
create temp files is in fd.c, which has no business invoking catalog
accesses, so we can't just say "we'll recheck the permissions when we're
going to create some temp files".  In any case this wouldn't improve the
behavior you were originally on about, which was surprising (to you)
failure to use a DBA-specified temp_tablespaces list.

>> 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.

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.  So the only loss of flexibility here
would be if you want unprivileged code to be able to set
temp_tablespaces for itself.  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.

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.
        regards, tom lane