Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id CABamaqMtYeRuciHtqQgk47nfFPuUO7XoeuVUjtkfUq0zNEnvKA@mail.gmail.com
Whole thread Raw
In response to Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
List pgsql-hackers

 
If all you need to do is lock a schema, you can just call
LockDatabaseObject(NamespaceRelationId, namespace_oid, 0,
AccessShareLock); there's no need to fake up an objectaddress just to
take a lock.  But I think that's not really all you need to do,
because somebody could drop the namespace between the time that you
decide what OID to lock and the time you acquire the lock.  So I think
you need something like what we did in RangeVarGetRelid().  See
attached patch.


Thanks Robert. But currently there are very few callers of RangeVarGetAndCheckCreationNamespace() function. For the sake of completeness we will have to introduce a call to this function while creating all other objects too.

Regards,
Nikhils
 
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: So where are we on the open commitfest?
Next
From: Emanuel Calvo
Date:
Subject: Re: [Feature Request] \dx show "options"