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 other such entries with invalid namespace values that need to be manually removed by the user. To prevent this from happening, we should take an AccessShareLock on the namespace of which the type, function, etc. is being added to.
Attached is a patch that covers the following CREATE commands: CREATE TYPE, CREATE FUNCTION, CREATE AGGREGATE, CREATE OPERATOR FAMILY, CREATE OPERATOR CLASS, and CREATE OPERATOR Example Reproduction Session1: CREATE SCHEMA testschema; Session1: BEGIN; Session1: CREATE TYPE testschema.testtype; Session2: DROP SCHEMA testschema; Session1: COMMIT; // The DROP SCHEMA schema succeeds in session 2 and session 1's COMMIT goes through without error but the pg_type entry will still be there for typname testtype. This example is for just a simple TYPE object but the other objects can be reproduced the same way in place of CREATE TYPE. Related Postgres 9.2 commit (note in commit message that "We need similar protection for all other object types"): https://github.com/postgres/postgres/commit/1575fbcb795fc331f46588b4520c4bca7e854d5c The patch itself is relatively trivial by just adding copy/paste lock acquires near other lock acquires. I wasn't sure if this needed a decently sized refactor such as the referenced commit above. Regards, Jimmy
concurrent_namespace_drop.patch
Description: Binary data
