TEMP tables applied
От | Bruce Momjian |
---|---|
Тема | TEMP tables applied |
Дата | |
Msg-id | 199902020357.WAA11757@candle.pha.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
I have applied TEMP tables to the tree, with documenation changes and a regression test. I am sure there are going to be some features that break with temp tables. First, there is no pg_type tuple to match the temp table name. There is one to match the system-generated temp table name, pg_temp.pid##.seq##. Temp table do not show up in \d, but you can see them in \dS as pg_temp*. Not sure if sequences/SERIAL/PRIMARY will work with temp tables. We either need them to work, or prevent them from being created. Testing will be necessary. One item I was not 100% happy with. In backend/catalog/heap.c and index.c, there is code that say: --------------------------------------------------------------------------- /* invalidate cache so non-temp table is masked by temp */ if (istemp) { Oid relid = RelnameFindRelid(relname); if (relid != InvalidOid) { /* * This is heavy-handed, but appears necessary bjm 1999/02/01 * SystemCacheRelationFlushed(relid) is not enough either. */ RelationForgetRelation(relid); ResetSystemCache(); } } --------------------------------------------------------------------------- I found that in my regression test where I create a table, and index, then a temp table and index, when I go to delete the temp index and table, the non-temps are deleted unless I use ResetSystemCache(). If I SystemCacheRelationFlushed(relid), the non-temp table is never deleted from the cache. It only seems to be a problem with indexes. Does anyone know why? Currently, it works, but I am not happy with it. Does anyone understand why the cache would not flush? Can someone debug a call to SystemCacheRelationFlushed(relid) and see why the invalidation is not happening on the non-temp relid. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: