From: | "Jaime Casanova" <systemguards(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces to provide a default location for |
Date: | 2007-03-18 19:05:07 |
Message-ID: | c2d9e70e0703181205i5adeaf48nd94541c0efb4b211@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers pgsql-patches |
On 3/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Jaime Casanova" <systemguards(at)gmail(dot)com> writes:
> > On 3/5/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | User Afn | 2007-03-18 23:02:41 | sparsegraph - sparsegraph: Imported Sources |
Previous Message | Tom Lane | 2007-03-18 17:57:34 | pgsql: Fix ecpg/preproc makefile for parallel builds: parser.o must |
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2007-03-18 19:17:06 | Re: ILIKE and indexes |
Previous Message | Guillaume Smet | 2007-03-18 18:30:35 | ILIKE and indexes |
From | Date | Subject | |
---|---|---|---|
Next Message | ITAGAKI Takahiro | 2007-03-19 00:33:54 | Re: ecpg threading vs win32 |
Previous Message | Tom Lane | 2007-03-18 16:18:33 | Re: Code-Cleanup: char* -> const char* |