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

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: schema
> "testschema" does not exist', so avoiding concerns about lock overhead
> seems the proposed patch is ok.

Thanks Fabrízio for the review.

I think so too, patching the low-level API is I think a proper way to go
particularly for back-branches because referencing objects which do not
exist at catalog level is a consistency problem.

Double-checking for the callers of QualifiedNameGetCreationNamespace,
CREATE STATISTICS could be called with CREATE TABLE LIKE, where it would
not get called but the table reference blocks the schema drop.

I am thinking about adding more tests to cover all the callers of
QualifiedNameGetCreationNamespace with:
- range type
- domain
- enum type
- statictics
- text search
- composite type

This way if any refactoring is done with this routine, then we don't
break schema lock logic. Andres, Tom and others, any objections?
--
Michael