Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces to provide a default location for
От | Jaime Casanova |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces to provide a default location for |
Дата | |
Msg-id | c2d9e70e0703181205i5adeaf48nd94541c0efb4b211@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces to provide a default location for (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [COMMITTERS] pgsql: Add GUC temp_tablespaces toprovide a default location for
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: