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