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? The real problem is
that heap/index_open open file _before_ acquiring any locks and
doesn't check t_xmax of relation/index tuple. I believe that
this is old problem. There are another ones, sure. 
Catalog cache code must be re-designed.

Vadim