RE: [HACKERS] DROP TABLE inside transaction block

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Monday, September 06, 1999 11:44 PM
> To: Leon
> Cc: Michael Simms; pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] DROP TABLE inside transaction block
>
>
> Leon <leon@udmnet.ru> writes:
> > Tom Lane wrote:
> >>>> Cant you just rename to a unique name, maybee in another directory,
> >>
> >> Not if other backends are also accessing the table.  Remember that to
> >> make this really work, the DROP would have to be invisible to other
> >> backends until commit.
>
> > Is that really needed? Remember that table's creation is not transparent
> > to other users - when someone attempts to create a table, others,
> > though can't see that table, cannot create a table with the same name.
> > So you can simply issue a draconian-level lock on a table being deleted.
>
> That's a good point --- we acquire exclusive lock anyway on a table
> about to be deleted, so just holding that lock till end of transaction
> should prevent other backends from trying to touch the table.
>

That reminds me.
DROP TABLE doesn't hold exlusive lock till end of transaction.
UnlockRelation() seems too early.
Here is a patch.

Seems ALTER TABLE doesn't acquire any lock for the target
relation. It's OK ?

regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** catalog/heap.c.orig    Tue Sep  7 08:52:04 1999
--- catalog/heap.c    Tue Sep  7 08:58:16 1999
***************
*** 1330,1336 ****
     rel->rd_nonameunlinked = TRUE;

-     UnlockRelation(rel, AccessExclusiveLock);
     heap_close(rel);

--- 1330,1335 ----