> -----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 ----