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. 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 > > [...] > > 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.
It seems to me that we are missing some dependency tracking in some of those cases. For example if you use a CREATE TYPE AS (...), then the DROP SCHEMA would fail without specifying CASCADE, and session 2 would block without a CASCADE. So instead of adding more code paths where LockDatabaseObject() is used, I would expect session 2 to block in get_object_address all the time, which looks a bit lossy now by the way. 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 available manually? Please let me play with what you have here a bit.. If you have an isolation test spec at hand, that would be helpful. -- Michael
signature.asc
Description: PGP signature
