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 по дате отправления:

Предыдущее
От: David Sauer
Дата:
Сообщение: BUG report: ERROR: Cannot expand tables; ....
Следующее
От: Ole Gjerde
Дата:
Сообщение: Re: [HACKERS] v6.5 release ToDo