RE: [HACKERS] DROP TABLE does not drop a table completely

> -----Original Message-----
> From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim
> Mikheev
> Sent: Monday, May 17, 1999 4:01 PM
> To: Hiroshi Inoue
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] DROP TABLE does not drop a table completely
> 
> 
> Hiroshi Inoue wrote:
> > 
> > > >
> > > > 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.
> 
> You're right - this should be done keeping in mind that DROP is allowed
> inside BEGIN/END (long transactions), but I'm not sure that this
> will help generally: does it matter when unlock dropped relation -
> in heap_destroy_with_catalog() or in commit?

Unlocking dropped relation before commit enables other transactions 
proceed and the transactions regard the relation as still alive before the
						   ^^^^^^^^^ 
commit of DROP TABLE command(It's right,I think). As a result,those 
transactions behave strangely,though I don't know more about the 
reason.

Thanks.

Hiroshi Inoue
Inoue@tpf.co.jp