Skip site navigation (1) Skip section navigation (2)

Re: global temporary tables

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 01:59:41
Message-ID: u2y603c8f071004241859j8317f9cai665cf3d75317930c@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-04-25 02:22:58
Subject: Re: global temporary tables
Previous:From: Jim NasbyDate: 2010-04-25 01:51:26
Subject: Re: global temporary tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group