From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <decibel(at)decibel(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: global temporary tables |
Date: | 2010-04-25 02:22:58 |
Message-ID: | s2i603c8f071004241922ze1498adah728dcb8d88d59980@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Apr 24, 2010 at 9:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Apr 24, 2010 at 9:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Unfortunately, I don't see much alternative to making smgr know
>>> something about the temp-ness of the relation, though I'm hoping to
>>> keep the smgr surgery to an absolute minimum. Maybe what we could do
>>> is incorporate the backend ID or PID into the file name when the
>>> relation is temp. Then we could scan for and nuke such files pretty
>>> easily. Otherwise I can't really think how to make it work.
>>
>> I think that could be a really good idea, mainly because it makes
>> post-crash cleanup MUCH safer: you can tell with certainty from the
>> filename that it's a leftover temp table. The notion of zapping files
>> just because we don't see them listed in pg_class has always scared the
>> heck out of me.
>>
>> We already know temp-ness at pretty low levels, like bufmgr vs localbuf.
>> Pushing it all the way down to smgr doesn't seem like a leap; in fact
>> I think it would eliminate a separate isTemp parameter in a lot of places.
>
> Eh? I don't see how it's going to do that.
Oh, maybe I do see. If we pass it to smgropen() and stash it in the
SMgrRelation, we don't have to keep supplying it later on, maybe?
Will investigate further.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-04-25 02:28:00 | Re: global temporary tables |
Previous Message | Robert Haas | 2010-04-25 01:59:41 | Re: global temporary tables |