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

> -----Original Message-----
> From: root(at)sunpine(dot)krs(dot)ru [mailto:root(at)sunpine(dot)krs(dot)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(at)tpf(dot)co(dot)jp