Re: tablespaces for temporary files - Mailing list pgsql-hackers

From Neil Conway
Subject Re: tablespaces for temporary files
Date
Msg-id 1099272934.31449.78.camel@localhost.localdomain
Whole thread Raw
In response to Re: tablespaces for temporary files  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, 2004-10-30 at 00:50, Tom Lane wrote:
> (1) What are the protection requirements for this variable?

I think it can be USERSET -- most commands let the user specify a
tablespace explicitly, and this is basically just another way of doing
that. The user executing the query will need CREATE privileges on the
tablespace they end up writing to.

> (2) I don't think that "undefined" is a particularly good concept for
> GUC variables.  Particularly not ones that you are envisioning setting
> from multiple places.

Hmm, ok. How about a token like "$database" that expands to the
tablespace of the current database?

> (3) I don't like the idea that a catalog lookup will be necessary before
> we can create or access temp files.  It would be quite unacceptable from
> a modularity standpoint to have the low-level routines that currently
> determine temp file paths do catalog accesses.

I don't agree it is "unacceptable", but it isn't ideal, granted.

> On the whole I'm unconvinced that this is worth the trouble.  One of the
> reasons for allowing people to move databases around is to determine
> where their temp files go.

I think this needlessly limits the flexibility of the system. Once
you've created a database and added a bunch of tables to it (in the DB's
tablespace), is there an easy way to change the tablespace used for
temporary files? What if the DBA has placed the database in a relatively
slow tablespace because that is suitable most of the time, but needs to
quickly execute a large OLAP query that consumes a lot of temporary
space? What if it makes sense at a particular installation for different
users to use different tablespaces for their temporary files?

I just think that always using the database's tablespace for temporary
files needlessly conflates two distinct concepts.

> Also, it's always been possible for people
> to change the pgsql_tmp subdirectory into a symlink.

This is a pain for the DBA, as you mention; it requires shutting down
the database; and it is fragile to begin with because the "pgsql_tmp"
directory is created on demand.

-Neil




pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: make check error on -HEAD
Next
From: Tom Lane
Date:
Subject: Re: Using ALTER TABLESPACE in pg_dump