Re: global temporary tables
От | Robert Haas |
---|---|
Тема | Re: global temporary tables |
Дата | |
Msg-id | s2i603c8f071004241922ze1498adah728dcb8d88d59980@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: global temporary tables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: global temporary tables
|
Список | pgsql-hackers |
On Sat, Apr 24, 2010 at 9:59 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Apr 24, 2010 at 9:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: