From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tablespaces for temporary files |
Date: | 2004-10-29 14:50:48 |
Message-ID: | 16012.1099061448@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> So I'd like to add a GUC variable called something like
> "scratch_tablespace". If undefined (the default), temporary files for
> sorting/etc. will be created in the current database's tablespace.
(1) What are the protection requirements for this variable?
(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.
(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.
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. Also, it's always been possible for people
to change the pgsql_tmp subdirectory into a symlink. While I know that
that isn't particularly DBA-friendly, it seems sufficient to me for what
I suspect is a third-order requirement.
Let's at least wait till we get some demand from the field before we
start inventing frammishes for tablespaces.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-10-29 19:08:10 | Re: [pgsql-hackers-win32] Win32 open items |
Previous Message | Bruce Momjian | 2004-10-29 13:20:24 | Re: Unixware 714 pthreads |