On 3/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 3/5/07, Tom Lane <[EMAIL PROTECTED]> 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

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to