Re: [HACKERS] DROP TABLE does not drop a table completely - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] DROP TABLE does not drop a table completely
Date
Msg-id 373FBEBF.C09E99B@krasnet.ru
Whole thread Raw
In response to DROP TABLE does not drop a table completely  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: [HACKERS] DROP TABLE does not drop a table completely  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Ole Gjerde
Date:
Subject: Re: [HACKERS] sgmr* vs. md*
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] DROP TABLE does not drop a table completely