pgsql: Add GUC temp_tablespaces to provide a default location for
Log Message:
-----------
Add GUC temp_tablespaces to provide a default location for temporary
objects.
Jaime Casanova
Modified Files:
--------------
pgsql/doc/src/sgml:
config.sgml (r1.104 -> r1.105)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml.diff?r1=1.104&r2=1.105)
pgsql/src/backend/commands:
indexcmds.c (r1.153 -> r1.154)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/indexcmds.c.diff?r1=1.153&r2=1.154)
tablecmds.c (r1.211 -> r1.212)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c.diff?r1=1.211&r2=1.212)
tablespace.c (r1.40 -> r1.41)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablespace.c.diff?r1=1.40&r2=1.41)
pgsql/src/backend/executor:
execMain.c (r1.284 -> r1.285)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.284&r2=1.285)
pgsql/src/backend/storage/file:
fd.c (r1.134 -> r1.135)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/file/fd.c.diff?r1=1.134&r2=1.135)
pgsql/src/backend/utils/misc:
guc.c (r1.369 -> r1.370)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c.diff?r1=1.369&r2=1.370)
postgresql.conf.sample (r1.204 -> r1.205)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/postgresql.conf.sample.diff?r1=1.204&r2=1.205)
pgsql/src/include/commands:
tablespace.h (r1.14 -> r1.15)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/commands/tablespace.h.diff?r1=1.14&r2=1.15)
pgsql/src/include/utils:
guc.h (r1.78 -> r1.79)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/guc.h.diff?r1=1.78&r2=1.79)
On 1/24/07, Bruce Momjian <momjian@postgresql.org> wrote:
Log Message:
-----------
Add GUC temp_tablespaces to provide a default location for temporary
objects.Jaime Casanova
the credit is for Albert Cervera Areny, I just did some minor
revisions and documentation:
http://archives.postgresql.org/pgsql-patches/2006-10/msg00141.php
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
Jaime Casanova wrote:
On 1/24/07, Bruce Momjian <momjian@postgresql.org> wrote:
Log Message:
-----------
Add GUC temp_tablespaces to provide a default location for temporary
objects.Jaime Casanova
the credit is for Albert Cervera Areny, I just did some minor
revisions and documentation:
http://archives.postgresql.org/pgsql-patches/2006-10/msg00141.php
CVS commit message added so release notes will have proper attribution.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
momjian@postgresql.org (Bruce Momjian) writes:
Add GUC temp_tablespaces to provide a default location for temporary
objects.
Jaime Casanova
I hadn't looked at this patch before, but now that I have, it is
rather broken.
In the first place, it makes no provision for RemovePgTempFiles() to
clean up leftover temp files that are in non-default places.
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.
Please revert until the submitter can come up with a better-designed
patch.
regards, tom lane
OK, patch reverted. Authors, would you please resubmit with fixes?
Thanks.
---------------------------------------------------------------------------
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
Add GUC temp_tablespaces to provide a default location for temporary
objects.
Jaime CasanovaI hadn't looked at this patch before, but now that I have, it is
rather broken.In the first place, it makes no provision for RemovePgTempFiles() to
clean up leftover temp files that are in non-default places.In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.Please revert until the submitter can come up with a better-designed
patch.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/rtmp/difftext/x-diffDownload+270-56
On 3/5/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.
ok, you are right... what do you suggest?
maybe move the GetTempTablespace function to somewhere in src/backend/utils?
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
"Jaime Casanova" <systemguards@gmail.com> writes:
On 3/5/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.
ok, you are right... what do you suggest?
maybe move the GetTempTablespace function to somewhere in src/backend/utils?
You missed the point entirely. Relocating the code to some other file
wouldn't change the objection: the problem is that fd.c mustn't invoke
any transactional facilities such as catalog lookups. It's too low
level for that.
You could perhaps do it the other way around: some transactional
code (eg the assign hook for a GUC variable) tells fd.c to save
some private state controlling future temp file creations.
BTW, if we are now thinking of temp files as being directed to
particular tablespaces, is there any reason still to have per-database
subdirectories for them? It might simplify life if there were just
one default temp directory, $PGDATA/base/pgsql_tmp/, plus one per
configured temp tablespace, $PGDATA/pg_tblspc/NNNN/pgsql_tmp/.
regards, tom lane
On 3/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jaime Casanova" <systemguards@gmail.com> writes:
On 3/5/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.ok, you are right... what do you suggest?
maybe move the GetTempTablespace function to somewhere in src/backend/utils?You missed the point entirely. Relocating the code to some other file
wouldn't change the objection: the problem is that fd.c mustn't invoke
any transactional facilities such as catalog lookups. It's too low
level for that.
oh, i see...
You could perhaps do it the other way around: some transactional
code (eg the assign hook for a GUC variable) tells fd.c to save
some private state controlling future temp file creations.
the problem with the assign hook function is that it can't read
catalogs too if we are in a non-interactive command...
so, we need a list with the oids of the tablespaces, we can initialize
this list the first time we need a temp file (i haven't seen exactly
where we can do this, yet), and if we set the GUC via a SET command
then we can let the assign hook do the job.
BTW, if we are now thinking of temp files as being directed to
particular tablespaces, is there any reason still to have per-database
subdirectories for them? It might simplify life if there were just
one default temp directory, $PGDATA/base/pgsql_tmp/, plus one per
configured temp tablespace, $PGDATA/pg_tblspc/NNNN/pgsql_tmp/.
what the NNNN directory shoud be, i understand ypur idea as just
$PGDATA/pg_tblspc/pgsql_tmp/...
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
On Sun, 2007-03-18 at 14:05 -0500, Jaime Casanova wrote:
On 3/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jaime Casanova" <systemguards@gmail.com> writes:
On 3/5/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.ok, you are right... what do you suggest?
maybe move the GetTempTablespace function to somewhere in src/backend/utils?You missed the point entirely. Relocating the code to some other file
wouldn't change the objection: the problem is that fd.c mustn't invoke
any transactional facilities such as catalog lookups. It's too low
level for that.oh, i see...
You could perhaps do it the other way around: some transactional
code (eg the assign hook for a GUC variable) tells fd.c to save
some private state controlling future temp file creations.the problem with the assign hook function is that it can't read
catalogs too if we are in a non-interactive command...so, we need a list with the oids of the tablespaces, we can initialize
this list the first time we need a temp file (i haven't seen exactly
where we can do this, yet), and if we set the GUC via a SET command
then we can let the assign hook do the job.BTW, if we are now thinking of temp files as being directed to
particular tablespaces, is there any reason still to have per-database
subdirectories for them? It might simplify life if there were just
one default temp directory, $PGDATA/base/pgsql_tmp/, plus one per
configured temp tablespace, $PGDATA/pg_tblspc/NNNN/pgsql_tmp/.what the NNNN directory shoud be, i understand ypur idea as just
$PGDATA/pg_tblspc/pgsql_tmp/...
Am I right in thinking we didn't get an updated patch in yet?
Any help needed here?
This seems a very important patch for manageability and it would be a
shame to miss out on it for 8.3 since its been a TODO item for so long.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Right, no updated patch submitted.
---------------------------------------------------------------------------
Simon Riggs wrote:
On Sun, 2007-03-18 at 14:05 -0500, Jaime Casanova wrote:
On 3/17/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Jaime Casanova" <systemguards@gmail.com> writes:
On 3/5/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.ok, you are right... what do you suggest?
maybe move the GetTempTablespace function to somewhere in src/backend/utils?You missed the point entirely. Relocating the code to some other file
wouldn't change the objection: the problem is that fd.c mustn't invoke
any transactional facilities such as catalog lookups. It's too low
level for that.oh, i see...
You could perhaps do it the other way around: some transactional
code (eg the assign hook for a GUC variable) tells fd.c to save
some private state controlling future temp file creations.the problem with the assign hook function is that it can't read
catalogs too if we are in a non-interactive command...so, we need a list with the oids of the tablespaces, we can initialize
this list the first time we need a temp file (i haven't seen exactly
where we can do this, yet), and if we set the GUC via a SET command
then we can let the assign hook do the job.BTW, if we are now thinking of temp files as being directed to
particular tablespaces, is there any reason still to have per-database
subdirectories for them? It might simplify life if there were just
one default temp directory, $PGDATA/base/pgsql_tmp/, plus one per
configured temp tablespace, $PGDATA/pg_tblspc/NNNN/pgsql_tmp/.what the NNNN directory shoud be, i understand ypur idea as just
$PGDATA/pg_tblspc/pgsql_tmp/...Am I right in thinking we didn't get an updated patch in yet?
Any help needed here?
This seems a very important patch for manageability and it would be a
shame to miss out on it for 8.3 since its been a TODO item for so long.--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Bruce Momjian wrote:
OK, patch reverted. Authors, would you please resubmit with fixes?
Thanks.---------------------------------------------------------------------------
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
Add GUC temp_tablespaces to provide a default location for temporary
objects.
Jaime CasanovaI hadn't looked at this patch before, but now that I have, it is
rather broken.In the first place, it makes no provision for RemovePgTempFiles() to
clean up leftover temp files that are in non-default places.In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporaryFile outside a transaction.Please revert until the submitter can come up with a better-designed
patch.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On 4/2/07, Bruce Momjian <bruce@momjian.us> wrote:
This has been saved for the 8.4 release:
mmm... sorry, i have been busy... how many time we have? i can send
something for friday...
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
Jaime Casanova wrote:
On 4/2/07, Bruce Momjian <bruce@momjian.us> wrote:
This has been saved for the 8.4 release:
mmm... sorry, i have been busy... how many time we have? i can send
something for friday...
Yes. Friday is fine, or even Monday.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
I think we will have to wait for 8.4 for this.
---------------------------------------------------------------------------
Jaime Casanova wrote:
On 4/2/07, Bruce Momjian <bruce@momjian.us> wrote:
This has been saved for the 8.4 release:
mmm... sorry, i have been busy... how many time we have? i can send
something for friday...--
regards,
Jaime Casanova"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +