DROP TABLE does not drop a table completely - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject DROP TABLE does not drop a table completely
Date
Msg-id 000a01bea00d$443b2b60$2801007e@cadzone.tpf.co.jp
Whole thread Raw
In response to [HACKERS] spinlock freeze ?(Re: INSERT/UPDATE waiting (another example))  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List 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 by date:

Previous
From: David Sauer
Date:
Subject: BUG report: ERROR: Cannot expand tables; ....
Next
From: Ole Gjerde
Date:
Subject: Re: [HACKERS] v6.5 release ToDo