Re: postmaster errors with index on temp table?
От | Philip Warner |
---|---|
Тема | Re: postmaster errors with index on temp table? |
Дата | |
Msg-id | 3.0.5.32.20000711230841.0270a100@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: postmaster errors with index on temp table? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: postmaster errors with index on temp table?
|
Список | pgsql-hackers |
At 09:27 10/07/00 -0400, Bruce Momjian wrote: >> >Yikes, I never looked in the postmaster log to see this. >> >> As Tom Lane said, it's non-fatal, and probably not important, but I worried >> me. I'll see if I can see the cause while I wait for people to test my new >> pg_dump with BLOB support. > I've had a look at temprel.c, and remove_all_temp_relations has the following: if (temp_rel->relkind != RELKIND_INDEX) { char relname[NAMEDATALEN]; /* safe from deallocation */ strcpy(relname, temp_rel->user_relname); heap_drop_with_catalog(relname, allowSystemTableMods); } else index_drop(temp_rel->relid); But, when a temp rel is dropped it seems that heap_drop_with_catalog also drops the indexes, so the error occurs when index_drop is called (at least I think this is the case). Certainly commenting out the last two lines *seems* to work. These lines were changed in rev 1.18 from 'heap_destroy*' calls to 'heap_drop' calls...did 'heap_destroy*' also delete related objects as heap_drop* now does? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: