DROP TABLE does not drop a table completely
От | Hiroshi Inoue |
---|---|
Тема | DROP TABLE does not drop a table completely |
Дата | |
Msg-id | 000a01bea00d$443b2b60$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | [HACKERS] spinlock freeze ?(Re: INSERT/UPDATE waiting (another example)) ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
Hi all, This mail is about the original cause of [HACKERS] spinlock freeze ?(Re: INSERT/UPDATE waiting (another example)). > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Hiroshi Inoue > Sent: Thursday, May 13, 1999 7:29 PM > To: Tom Lane; Wayne Piekarski > Cc: pgsql-hackers@postgreSQL.org > Subject: [HACKERS] spinlock freeze ?(Re: INSERT/UPDATE waiting (another > example)) > > [snip] > > > > Then another one after restarting everything: > > > > ERROR: cannot open segment 1 of relation sessions_done_id_index > > > > I got the same error in my test cases. > I don't understand the cause of this error. > I got this error message by dropping a table while concurrent transactions inserting rows to the same table. I think other transactions should abort with message "Table does not exist". But in most cases the result is not so. It seems that other transactions could proceed before DROP TABLE command is completed. AFAIC heap_destroy_with_catalog() acquires AccessExclusiveLock and releases the lock inside the function. I think that heap_destroy_with_catalog() (or upper level function) should not release the lock. Comments ? Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: