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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jimmy Yih <jyih(at)pivotal(dot)io>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace
Date: 2018-09-06 18:56:27
Message-ID: 20180906185627.GM2726@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 manually before and after adding the AccessShareLock acquire on
> the schema.

(You should avoid top-posting, this is not the style of the lists.)

Thanks. One problem I have with what you have here is that you just
test only locking path as the session dropping the session would just
block on the first concurrent object it finds. If you don't mind I am
just stealing it, and extending it a bit ;)
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-09-06 19:01:14 Re: Collation versioning
Previous Message James Coleman 2018-09-06 18:04:44 Re: [PATCH] Incremental sort (was: PoC: Partial sort)