Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-11 Thread Robert Haas
On Wed, Sep 5, 2018 at 1:05 AM, Tom Lane wrote: >> Would expanding this a git further really be that noticeable? > > Frankly, I think it would be not so much "noticeable" as "disastrous". > > Making the overhead tolerable would require very large compromises > in coverage, perhaps like "we'll

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-08 Thread Michael Paquier
On Sat, Sep 08, 2018 at 04:21:34PM -0400, Tom Lane wrote: > I'm still not very happy about this, mainly because it seems like > (a) it's papering over just a small fraction of the true problem Check. > (b) there's been no discussion about cost-benefit tradeoffs. Noted. I am not sure how to

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-08 Thread Tom Lane
Michael Paquier writes: > This way if any refactoring is done with this routine, then we don't > break schema lock logic. Andres, Tom and others, any objections? I'm still not very happy about this, mainly because it seems like (a) it's papering over just a small fraction of the true problem

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-08 Thread Michael Paquier
On Thu, Sep 06, 2018 at 05:19:15PM -0300, Fabrízio de Royes Mello wrote: > I also run some similar tests as Jimmy pointed and using PLpgSQL to execute > DDLs and the new consistent behavior is ok. Also I run one session using > DROP SCHEMA at end and after COMMIT the session 2 report 'ERROR:

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-06 Thread Fabrízio de Royes Mello
On Thu, Sep 6, 2018 at 4:22 PM Michael Paquier wrote: > > On Wed, Sep 05, 2018 at 09:23:37AM -0700, Andres Freund wrote: > > Well, we kinda do, during some of their own DDL. CF > > AcquireDeletionLock(), RangeVarGetAndCheckCreationNamespace(), and other > > LockDatabaseObject() callers. The > >

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-06 Thread Michael Paquier
On Wed, Sep 05, 2018 at 09:23:37AM -0700, Andres Freund wrote: > Well, we kinda do, during some of their own DDL. CF > AcquireDeletionLock(), RangeVarGetAndCheckCreationNamespace(), and other > LockDatabaseObject() callers. The > RangeVarGetAndCheckCreationNamespace() even locks the schema an

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-06 Thread Michael Paquier
On Wed, Sep 05, 2018 at 12:14:41AM -0700, Jimmy Yih wrote: > Attached the isolation spec file. I originally was only going to fix the > simple CREATE TYPE scenario but decided to look up other objects that can > reside in namespaces and ended up finding a handful of others. I tested > each one

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-05 Thread Andres Freund
Hi, On 2018-09-05 01:05:54 -0400, Tom Lane wrote: > Andres Freund writes: > > On September 4, 2018 9:11:25 PM PDT, Tom Lane wrote: > >> I think that line of thought leads to an enormous increase in locking > >> overhead, for which we'd get little if any gain in usability. So my > >>

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-05 Thread Jimmy Yih
> > Something which would be good to have for all those queries is a set of > isolation tests. No need for multiple specs, you could just use one > spec with one session defining all the object types you would like to > work on. How did you find this object list? Did you test all the > objects

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-04 Thread Tom Lane
Andres Freund writes: > On September 4, 2018 9:11:25 PM PDT, Tom Lane wrote: >> I think that line of thought leads to an enormous increase in locking >> overhead, for which we'd get little if any gain in usability. So my >> inclination is to make an engineering judgment that we won't fix this.

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-04 Thread Andres Freund
On September 4, 2018 9:11:25 PM PDT, Tom Lane wrote: >Michael Paquier writes: >> On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote: >>> When an empty namespace is being initially populated with certain >objects, >>> it is possible for a DROP SCHEMA operation to come in and delete the

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-04 Thread Tom Lane
Michael Paquier writes: > On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote: >> When an empty namespace is being initially populated with certain objects, >> it is possible for a DROP SCHEMA operation to come in and delete the >> namespace without using CASCADE. > It seems to me that we

Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-04 Thread Michael Paquier
On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote: > When an empty namespace is being initially populated with certain objects, > it is possible for a DROP SCHEMA operation to come in and delete the > namespace without using CASCADE. These objects would be created but are > left unusable.

Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

2018-09-04 Thread Jimmy Yih
Hello, When an empty namespace is being initially populated with certain objects, it is possible for a DROP SCHEMA operation to come in and delete the namespace without using CASCADE. These objects would be created but are left unusable. This is capable of leaving behind pg_class, pg_type, and