From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Jaime Casanova" <systemguards(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces toprovide a default location for |
Date: | 2007-04-02 17:45:22 |
Message-ID: | 1175535922.4386.1095.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers pgsql-patches |
On Sun, 2007-03-18 at 14:05 -0500, Jaime Casanova wrote:
> 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/...
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-04-02 17:54:59 | Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces toprovide a default location for |
Previous Message | Bruce Momjian | 2007-04-02 17:18:45 | pgsql: Done: < * Support a data type with specific enumerated values |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-04-02 17:52:47 | Re: One-time plans |
Previous Message | Bruce Momjian | 2007-04-02 17:15:35 | Re: Last minute mini-proposal (I know, Iknow)forPQexecf() |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-04-02 17:54:59 | Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces toprovide a default location for |
Previous Message | Andrew Dunstan | 2007-04-02 17:43:46 | Re: Current enums patch |